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TOPPING UP A SUBSCRIBER'S ACCOUNT FOR A MULTIMEDIA 
SERVICE ON A COMMUNICATIONS NETWORK WHILE 
THE SERVICE IS BEING PROVIDED 

5 RELATED APPLICATIONS 

This application claims the benefit under 35 U.S. C. §1 19(a) to commonly-owned 
U.S. provisional patent application serial no. 60/295,453, entitled Media Insensitive, Real 
Time, Low Balance Threshold Notification and Processing Mechanism (akathe "TOP UP, 
POP UP"), filed June 1, 2001, under attorney docket no. W00561/70002, U.S. provisional 

10 patent application serial no. 60/344,538, entitled Implementing an Intelligent Network 

Service for a Packet-Switched Service Using a Node Interfacing a Mobile Communications 
Network to a Packet Data Network, filed on October 19, 2001 under attorney docket no. 
W00561/70006, and U.S. provisional patent application serial no. 60/357,940, entitled 
Implementing an Intelligent Network Service for a Packet-Switched Service Using a Node 

1 5 Interfacing a Mobile Communications Network to a Packet Data Network, filed on February 
18, 2002 under attorney docket no. W00561/70007, each of which is incorporated herein by 
reference in its entirety. 

Commonly-owned U.S. patent application entitled Implementing an Intelligent 
Network Service for a Packet-Switched Service Using a Node Interfacing a Mobile 

20 Communications Network to a Packet Data Network, filed herewith under attorney docket 
no. W00561/70008 (the.Ang application) is incorporated herein by reference in its entirety. 



FIELD OF INVENTION 

25 The present disclosure relates generally to the field of communications networks and 

more specifically to notifying a subscriber of a communications network that a threshold 
amount of a multimedia service provided on the network has been consumed while the 
service is being provided and enabling the subscriber an opportunity to add value to an 
account balance for the multimedia service (i.e., "top-up") while the service is being 

3 0 provided, thereby extending the duration that the service is provided. 



DESCRIPTION OF THE RELATED ART 
For typical communications service providers, it is desirable to be able to measure 
and price communication services, including audio (e.g., voice) services, data services, 
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video services, and multimedia services, and present bills for such services. As used herein, 
an "audio service" is a service that includes an exchange voice content between two or more 
nodes of a communications network, a "data service" is a service that includes an exchange 
of data content between two or more nodes of a communications network, a "video service" 
is a service that includes an exchange of video content (i.e., one or more sequential images) 
between two or more nodes of a communications network, and a "multimedia service" is a 
service that includes an exchange of data content or video content, or any combination of 
video content, audio (e.g., voice) content and data content, between two or more nodes of a 
communications network. A service that exchanges only voice content is not a "multimedia 
service" as defined herein. 

It should be understood that although a service or communication includes the 
exchange of one or more types of content, such service and communication also may 
include the exchange of other information in addition to content, including signaling, control 
and formatting information, in accordance with one or more protocols. 
Billing Systems for Voice Services 

Fig. 1 illustrates an example of a traditional telecommunications system 100 for 
providing voice services that utilizes a postpaid billing method. As used herein, a "voice 
service" is a service providing the exchange of voice content between nodes of a 
communications network. System 100 may be a mobile or landline telecommunications 
network. 

For example, a session may be initiated by calling party 102 with called party 1 14 
across originating central office 104, long distance network 1 16 and terminating central 
office 113. At the beginning of the session, the system 100 authenticates a subscriber (i.e., 
subscriber) 102 of a particular service, authorizes that the subscriber is entitled to access the 
service, and in some cases validates the subscriber has sufficient creditworthiness or prepaid 
amounts to at least begin using the service. The service can then be rendered and sufficient 
information recorded in a data record often referred to as a Call Detail Record (CDR). 
Information embodied in fields in the CDR such as duration of a session or volume of bytes 
consumed during a session, is monitored by network elements, such as at the Originating 
Central Office 14, and entered into the CDR. Once the session is finished, a completed 
CDR is sent to a Billing Collector 106. In some cases, the Billing Collector periodically 
forwards a batch of the CDRs to a Billing Mediator 108, which converts the specific CDR 
formats from a plurality of network elements to a common format understood by a Billing 
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System 1 10. The billing system typically determines the underlying price for a provided 
service by applying a rate for the service to the CDR to produce a final price for the service. 
The billing system then may merge me final price for the service onto me subscriber's bill 
112. 

As technology has changed, adding more powerful processing capabilities, it has 
become possible to perform some of the steps of billing for a voice service in real-time or 
quasi-real-time. For example, rating a service, which was described above as being 
performed after the voice service was performed, may occur simultaneously with the 
authorization step at the beginning of a session for the service. With such rate information, 
it is possible to determine a specific time quantity (for time-based metering) or a specific 
volume quantity (for volume based metering of volumes of data) for which a voice service 
can be provided before such provisioning should be stopped (i.e., the call should be 
disconnected). For example, before providing a voice service, the balance present in a 
prepaid account may be divided by the rate per unit of time or volume for the service to 
produce a service value. This voice service value could then be used to preset a time or 
volume threshold. The voice service can then be metered until the threshold is reached, at 
which time higher level processing can be notified that the threshold has been reached. This 
type of prepaid processing is present in several voice telecommunications systems 
worldwide. As used herein, a "prepaid account" is a subscriber's account for a service for 
which the subscriber has subscribed for prepaid charging. 

Typically, in such voice telecommunications systems, in response to a threshold 
being reached, the system will interrupt the voice call in progress and, using a Voice 
Response Unit (VRU), warn the calling party about the impending disconnection that will 
occur. More extensive processing can also occur at this point. The VRU prompt may offer 
the caller an opportunity for adding value to an account (i.e., "topping-up^' an account) by 
entering a new unique code printed on a pre-paid phone card (i.e., "top-up card"), for 
example, by touch tone entry. In places that provide the ability to top-up (e.g., several 
European countries), top-up cards are typically sold through retail locations like 
supermarkets, convenience stores or gas stations. 

Fig. 2 illustrates an example of atypical system 101 for implementing real-time 
prepaid charging for voice calls. System 101 may be a mobile or landline 
telecommunications network. 
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Calls are routed from a network 1 1 6 to a Prepaid Adjunct Processor 118, which is 
responsible for metering the call, identifying when a prepaid threshold has been reached, 
introducing a Voice Response Unit to alert the Calling Party of the impending call 
disconnect and offering a top-up opportunity. In the embodiment of system 101, the rating 
5 and account balance information is stored in a separate computer 120 and the functions 
performed by the Prepaid Adjunct Processor are initialized by computer 120. 

In another embodiment of system 101, the Prepaid Adjunct Processor 1 1 8 may be 
embedded directly into a Central Office (e.g., Central Office 104) and may be implemented 
using Intelligent Network Services, which are described in more detail below. 

10 In an embodiment of system 1 0 1 , the calling party 1 02 makes a prepayment into an 

electronic account, which is stored in a database on the network. Prepayments can be made 
in a number of fashions, where the most prevalent is to go to a retail point of sale such as a 
supermarket or convenience store and pay a sum of money to acquire a prepaid card. The 
prepaid card has a unique code that represents a link to the electronic account. To access the 

1 5 value stored in the electronic account, the calling party or party to be billed enters an access 
code that routes the call to the Prepaid Adjunct Processor 118. In an alternative 
embodiment, the calling party terminal (i.e., subscriber terminal) may be uniquely identified 
as a prepaid account holder and be automatically routed to the Prepaid Adjunct Processor. 
For example, a unique calling party identification (e.g., an International Mobile Subscriber 

20 Identity (IMSI) for a mobile telecommunications system) may be used as the key to the 
electronic account, as opposed to the unique code on a prepaid card. 

In response to the Prepaid Adjunct Processor 118 receiving the call, the calling party 
42 is asked for the unique code to allow the adjunct processor to identify the electronic 
account in which the prepaid amount is resident. The caller is then requested to enter the 

25 identification of the called party 1 14 (i.e., the phone number) to which the call should be 

sent. These two pieces of information are communicated to a computer (e.g., computer 120) 
that maintains the electronic account and has the ability to "rate" the cost of making a call to 
the called party 1 14. Based on the monetary balance remaining in the electronic account 
and the cost of the service to be rendered (e.g., dollars per unit of time or volume), a rating 

3 0 and accounting subsystem can calculate the number of minutes or volume of information 
united (e.g., bytes) left to reach a prepaid threshold or spending threshold. The 
rating/accounting computer 120 communicates a message to the Prepaid Adjunct Processor 
1 1 8 that allows the Prepaid Adjunct Processor to initialize an internal meter which measures 
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the duration for which the call is in progress (starting when the called party 1 14 answers) or 
the volume of information units that flow through the transport path during the call, starting 
from when a voice session for the call is established. 

When the Prepaid Adjunct Processor 1 1 8 determines that the prepaid threshold for 
the call is reached, a low balance warning is sent to the calling party by either placing the 
called party on hold and inserting a VRU or by bridging the VRU directly into the call. It is 
sometimes preferred that the call is suspended during this period so the warning cannot be 
heard by the called party, and it is sometimes preferable for both parties to hear the warning. 
Additional processing can also be performed at this time to allow extension of the current 
call by topping up the prepaid account. 

In this scenario, the called party 1 14 is typically placed on hold. The Prepaid 
Adjunct Processor 1 18 is conditioned to receive touch tone input, and the calling party 42 is 
offered the opportunity via a VRU message to enter a new unique code from a prepaid card 
purchased in a retail location. Once the unique code has been received and verified, and the 
meter of the Prepaid Adjunct Processor 1 18 has been re-initialized with the new values, the 
suspended call is allowed to continue. Most often, the existing electronic account and the 
initial unique code of the calling party survive the call when it is completed, and the unique 
code and associated electronic account of the prepaid card used to add value to the existing 
account are marked as depleted once the value from the account has been transferred to the 
existing account. 

Mobile Communications Networks 

The need to meter, price and bill communications services is recognized on mobile 
(i.e., wireless) communications networks (MCNs), as MCNs (mobile telecommunications 
networks, mobile data communications networks and combinations thereof) are having a 
growing impact on the communications industry. In addition to enabling communication 
services to be provided by service providers, operators of MCNs often provide Intelligent 
Network Services (INSs), for example, prepaid charging, for their subscribers as well. 

There are several types of MCNs, as well as several types of MCN network 
elements, technologies and configurations. For a better understanding of the problems and 
solutions set forth below, these several types of MCNs, network elements, technologies and 
configurations will now be described. 

As used herein, a "mobile communications network" or "MCN" is a 
communications network including a plurality of network resources that enable wireless 
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communications between two or more of the plurality of network resources. As used herein, 
"plurality" means two or more. MCNs are often referred to as Public Land Mobile 
Networks (PLMNs). Several types of MCNs are known, and some are in use today, 
including Global System for Mobile communications (GSM), General Packet Radio Service 
5 (GPRS), Universal Mobile Teleconmiunications System (UMTS), a plurality of types of 
Code-Division Multiple Access-based communications networks (e.g., cdmaOne, 
cdma2000, etc.), Wireless Personal Area Networks (PANs), for example, Bluetooth or a 
wireless PAN in accordance with IEEE 802.15, and Wireless Local Area Networks 
(WLANs), for example, HiperLan 2 or a WLAN in accordance with IEEE 802. 1 1 (e.g., 

10 802.11b (Wi-Fi), 802.11a and 802.1 lg). 

GPRS originally was developed and is often implemented as an add-on to existing 
GSM networks. Thus, a GSM network and a GPRS network are often part of an MCN 
referred to herein as a GSM/GPRS network. GSM, often referred to as a 2 nd Generation or 
2G network, is described in more detail in: 3rd Generation Partnership Project Technical 

1 5 Specification Group Services and System Aspects, Digital cellular telecommunications 

system (Phase 2+), GSM Release 1999 Specifications (3GPP TS 01. 0l\, the entire contents 
of which are hereby incorporated by reference. J 

The 3 rd Generation Partnership Project (3 GPP) specifies Europejan-centric mobile 
communication standards such as GPRS and UMTS. The 3 rd Generation Partnership Project 

20 II (3GPP2) is an organization that specifies more US-centric mobile communications 
standards such as CDMA 2000 standards. 

GPRS, often referred to as a 2.5G network, is described in more detail in: 3 rd 
Generation Partnership Project, Technical Specification Group Services and System 
Aspects, Digital cellular telecommunication system (Phase 2+), General Packet Radio 

25 Service (GPRS), Service description, Stage 2, Release 1998 (3GPP TS 03. 60), the entire 
contents of which are hereby incorporated by reference. 

UMTS, often referred to as a 3 rd Generation or 3G network, is described in technical 
specifications published by the 3rd Generation Partnership Project, including 3GPP TS 
23.101, whereas packet-switched services of UMTS are described in 3 GPP TS 23.060. The 

30 entire contents of 3GPP TS 23.101 and 3 GPP TS 23.060 are each being hereby incorporated 
by reference. 

CdmaOne, often referred to as a 2.5G network, is described in more detail in: ANSI/ 
Telecommunications Industry Association (TIA)/EIA-95-A and 95-B Standard, Mobile 
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terminal-Base Station Compatibility Standard for Wideband Spread Spectrum Cellular 
Systems, ANSI/TWEIA-41-C and 41-D Standard Cellular Radiotelecommunications 
Intersystem Operations, the entire contents of which are hereby incorporated by reference. 
Cdma2000 is described in more detail in technical specifications published by the 
5 3rd Generation Partnership Project II, including A.S0001-A 3GPP2, Access Network 

Interfaces Interoperability Specification - Release A, the entire contents of which is hereby 
incorporated by reference. 

Some MCNs only are capable of implementing circuit-switched voice services. As 
used herein, a "chcuit-switched voice service" is a voice service, for example, plain old 

10 telephone service (POTS), implemented using circuit-switched communications (analog or 
digital). As used herein, a "circuit-switched voice communication" is a communication 
including voice content that is transmitted along a network path (i.e., a connection or circuit) 
established between two endpoints for which a portion of bandwidth (e.g., a time slot) of 
each link along the path is exclusively reserved for a duration of the connection. All 

1 5 communications transmitted from one endpoint to the other endpoint travel the same path 
across the network defined for the connection, which is established before communications 
begin. For example, for a telephone call, a connection is established between at least two 
parties and reserved for a duration of the call. Typically, after a connection has been 
established, circuit-switched voice communications include a connection identifier and a 

20 destination identifier (e.g., telephone number) from which network nodes determine where 
to route (i.e., switch) the communication. A Public Switched Telephone Network (PSTN) is 
an example of a communications network that provides circuit-switched voice services. A 
GSM network is an example of an MCN that provides circuit-switched voice services. 

Other MCNs are capable of implementing packet-switched services in addition to or 

25 as an alternative to circuit-switched voice services. As used herein, a "packet-switched 
service" is a service implemented using packet-switched communications, for example, an 
Internet access service provided by an Internet Service Provider (ISP). 

As used herein, a "packet-switched communication" is a communication transmitted 
between two nodes of a communications network using packet-switching, where the 

30 communication comprises one or more packets. As used herein, a "session" is a logical 
relationship established between at least two network entities for a period of time. As used 
herein, a "packet" is a unit of information exchanged between modules of a communications 
network, where such modules may reside on a same or different node of the 
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communications network. As used herein, to "exchange" means to transmit to transmit 
and/or receive. Packets are often referred to as "frames" in the network communications 
industry. Using packet-switching, each packet exchanged between the two nodes may travel 
a different path across the network and may encapsulate any of a variety of media content, 
including audio (e.g., voice), video, and data, or combinations thereof. Using packet- 
switching, each packet of a packet-switched communication may include a source identifier 
(e.g., IP address) and a destination identifier (e.g., IP address) from which network nodes 
determine where to route or switch each packet of the communication. A Local Area 
Network (LAN) is an example of a communications network that can provide packet- 
switched services. A GPRS network is an example of an MCN that can provide packet- 
switched services. 

As used herein, a "user terminal" is a communication device that serves as an 
endpoint in a communications network and at which communications may terminate and/or 
originate. Some examples of user terminals include work stations, PCs, laptops, telephones, 
pagers, Blackberry™ brand devices, PCS devices, personal digital assistants (PDAs), etc. 

As used herein, a "mobile terminal" or "MT" is a user terminal capable of 
communicating (i.e., receiving and/or transmitting communications) with other network 
resources through an air interface (i.e., using a carrier wave). 

As used herein, a "mobile subscriber" or "subscriber" is a user of an MT who 
subscribes to one or more services provided by an operator of an MCN. 

Fig. 3 is a block diagram illustrating a communications network 1 that includes at 
least MCNs 2 and 4, one or more packet data networks (PDNs) 6, a public switched 
telephone network (PSTN) 8 and one or more other communications networks 10, which 
each can be any of a variety of types of communications networks. A PDN may be any 
communications network capable of communicating information encapsulated in packets, 
for example, an Internet Protocol-based (IP-based) network, an X.25-based network, or an 
Asynchronous Transfer Mode (ATM) network. 

The MCN 2 may include one or more MTs 1 8 configured to communicate with a 
wireless access sub-network (WAS), for example, a Base Station Subsystem (BSS) of a 
GSM, GPRS or UMTS network or a Radio Access Network (RAN) of a CDMA-based 
network. The MCN 2 may include one or more WASs 12 that are each interfaced to a 
network services sub-network (NSS) 10 of the MCN 2. 
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Fig. 4 illustrates a WAS 12 of an MCN 2 in more detail. A WAS 12 provides the 
radio link between an MT and an NSS. A WAS 12 may include any of one or more wireless 
access portals (WAPs) 30, for example, a Base Transceiver Station (BTS) and radio tower 
of a BSS or a RAN. A WAP 30 may include one or more radio transceivers. In a typical 
MCN, a range of a transceiver defines a cell. A WAP 30 handles the radio-link protocols 
for communication with an MT. 

Each of the one or more WAPs 30 may be connected to a wireless access sub- 
network controller (WASC), for example, a Base Station Controller (BSC) of a BSS or a 
Radio Network Controller (RNC) of a RAN. The WASC 32 manages the radio resources 
for one or more WAPs 30. For example, the WASC may handle radio-channel set up, 
frequency hopping, and handoffs between WAPs. The WASC serves as a logical interface 
between an MT and one or more switching modules of the NSS 10. 

The WASC 32 may be configured to discriminate between packet-switched 
communications and circuit-switched communications. The WASC 32 may include a 
packet control unit (PCU) 33 that enables the WASC 32 to handle packet-switched 
communications and route them to packet-switching module (PSM) 36 of NSS 10, whereas 
circuit-switched voice communications are routed to chcuit-switching module (CSM) 34. 
Network Services Sub-network of a Mobile Communications Network 
Fig. 5 illustrates the NSS 10 of MCN 2 in more detail. A typical NSS 10 performs 
the switching of communications between subscribers of the MCN 2 and between a 
subscriber of the MCN 2 and a network resource on another network (e.g., another MCN 4, 
a PDN 6, a PSTN 8 or another communications network 10). The NSS 10 also may handle 
the mobility management operations for the MCN 2 and provide a variety of other services. 
The NSS 10 may include any of one or more CSMs 34A, one or more PSMs 36A, one or 
more PDN Interface Modules (PIMs) 44A and 46B, one or more Service Control Function 
(SCF) modules 48, one or more subscriber information registers (SIRs) 50, one or more 
charging gateways 45 and one or more billing systems 47. 

An NSS (e.g., NSS 10) that includes both a CSM and a PSM enables subscribers to 
have access to both chcuit-switched voice services and packet-switched services. For 
example, if the NSS 10 is part of a GSM/GPRS network, one or more of the CSMs may be a 
Mobile Switching Center (MSC) that may include a Visitor Location Register (VLR), and 
the PSM may be a Serving GPRS Support Function (SGSF) module. The SGSF module 
may be implemented on a Serving GPRS Support Node (SGSN) of the GPRS network, or 
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may be implemented on a GPRS Support Node (GSN) that also may include a Gateway 
GPRS Support Function (GGSF) module. 

Alternatively, if the NSS 10 is part of a GSM network mat implements only circuit- 
switched voice services, the NSS 10 may not include any PSMs, but may include one or 

5 more MSCs that each may include a (Visitor Location Register) VLR. 

The switching modules (CSMs and PSMs) may provide a variety of services for the 
NSS, including registration of subscribers, authentication, ciphering, location updating (of 
subscribers), handoffs between WASCs and switching. For example, the switching nodes 
may switch communications, originating from an MT and received from a WASC, to an 

1 0 appropriate destination, for example, another WASC, another module or node of the NSS 
10, a node of another MCN 4, a PIM (e.g., 44A, 44B) for interfacing to a PDN (e.g., 6A, 
6B), a node of the PSTN 8 or a node of another communication network. The switching 
modules may provide other services. 

A PIM (e.g., 44A and 44B) serves as a logical interface between an MCN 2 and a 

1 5 PDN (e.g., 6A, 6B) external to the MCN 2. PDNs 6 A and 6B may be any type of packet 
data network, including the Internet or a corporate LAN. To serve as such logical interface, 
a PIM may be configured to implement protocols specific to the MCN 2 and protocols 
specific to a PDN 6. For example, for a GPRS network, a GGSF module may serve as a 
PIM and be configured to implement one or more packet data protocols, for example, the 

20 User Datagram Protocol (UDP) or the Transport Control Protocol (TCP) and IP or X.25 
protocols. The GGSF module further may be configured to implement one or more GPRS 
protocols such as the GPRS Tunneling Protocol (GTP). 

A PIM (e.g., PIM 44A or 44B) may be configured to exchange communications 
(e.g., a Data Call Detail Record (DCDR)) with a charging gateway 45, which may in turn 

25 aggregate such DCDRs from one or more PIMs and forward them to a billing system 47 for 
further processing. 

PDN 6B may include a PDN node 66. PDN node 66 may be configured with one or 
more applications that provide one or more services to subscribers. As such, PDN node 66 
may be an application server. 
30 To implement a session between an MT 1 8 A of the MCN 2 and a node 66 of the 

PDN 6A, the PSM 36A may switch communication packets received from the WASC 32A 
to PIM 44A, which exchanges communication packets (using the appropriate protocols) 
with the appropriate nodes of the PDN 6Ato communicate with node 66. 
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Different types of MCNs may have different implementations of a PIM. For a 
CDMA-based network, a PIM may be a Packet Data Serving Node (PDSN). 

For a GPRS network, a PIM may be a GGSF module, which is configured to 
implement GPRS-defined interfaces: a Gi interface to a PDN, a Gn interface to an SGSF 
5 module of the MCN and a Gp interface to an SGSF module from another MCN. On some 
GPRS networks, an SGSN and a GGSN are combined on the same network node, 
sometimes referred to as a GPRS Support Node (GSN). Even on such GSNs, however, the 
GGSF module and the SGSF module typically are configured as separate, logically- 
interconnected modules. 

1 0 The Subscriber Information Register (SIR) 50 may include an entry for each 

subscriber of the MCN 2, the entry representing a subscriber profile of information about the 
subscriber, including administrative information about the subscriber, the location of the MT 
currently being used by the subscriber and information about services to which the 
subscriber is registered. On a GSM/GPRS network, the SIR may be a Home Location 

1 5 Register (HLR), and an MSC, a GGSF module and a SGSF module may communicate with 
the HLR in accordance with the Mobile Applications Part (MAP) protocol, GPRS Release 
1998 or 1999, on top of an SS7 protocol. Other protocols may be used. GPRS Release 
1998 is described in more detail in: 3rd Generation Partnership Project; Technical 
Specification Group Core Network; Digital cellular telecommunications system (Phase 2+); 

20 Organization of subscriber data; Release 1998 (3GPP TS 03. 08), and 3rd Generation 
Partnership Project; Technical Specification Group Core Network; Subscriber data 
management; Stage 2 Release 1998 (3GPP TS 03.16), the entire contents of which are 
hereby incorporated by reference. 

GPRS Release 1999 is described in more detail in: 3rd Generation Partnership 

25 Project; Technical Specification Group Core Network; Organization of subscriber data; 
Release 4 (3GPP TS 23.008), and 3rd Generation Partnership Project; Technical 
Specification Group Core Network; Subscriber data management; Stage 2; Release 4 
(3GPP TS 23. 016), the entire contents of which are hereby incorporated by reference. 
Intelligent Network Services 

30 The MCN 2 may include one or more SCF modules 48 to provide and control 

execution of one or more INSs to subscribers. An INS is an advanced communication 
service beyond traditional services such as setting up, maintaining and terminating a call or 
session and other traditional telephony services such as call waiting and call forwarding. 
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Several existing technologies today implement INSs by having switching modules (e.g., a 
PSM or CSM) consult (i.e., exchange communications with) an SCF module to implement 
the service. For example, on some existing networks, to implement an INS for a circuit- 
switched telephone call, in response to receiving all of the digits for a telephone number, a 
5 CSM initiates communications with an SCF module before contacting other network nodes 
to establish the connection for the telephone call. Conversely, if no INS is to be 
implemented for the circuit-switched telephone call, the CSM will not initiate 
communications with an SCF module before proceeding with establishing the connection. 
For a circuit-switched telephone call for which an INS is not to be implemented, a 

10 CSM may merely access its routing table to determine where to route the telephone call 
based on the digits received from the subscriber. If a subscriber has subscribed to an INS, 
then the routing table may be configured (e.g., programmed with "hooks") to cause the CSM 
to initiate communications with an SCF module in response to receiving telephone number 
digits from the subscriber or in response to receiving a specific sequence of digits from the 

1 5 subscriber, or in response to values of any of a number of other parameters. 

As will be described in more detail below, an SCF module may be configured with 
the "intelligence" for implementing the INS. The SCF module may instruct the CSM to 
switch a telephone call based on any of a number of parameters, for example, time of day, 
location from which the call is originated, the destination for which the call is bound, etc. 

20 Types of known INSs include Toll-free, Virtual Private Network (VPN), Personal 

Number, Premium Rate, Calling Card, Toll-Shared, Number Portability and Prepaid 
Charging. As used herein, "prepaid charging" refers to a type of charging for a service 
where a subscriber pays for an amount of the service before the service is provided. 

Currently, and over the last few years, INSs are being developed and integrated into 

25 existing MCNs with each new release of a particular technology. For example, the 

International Telecommunication Union Telecom Standardization (ITU-T) body specifies 
INSs in Capability Set 1 (CS-1) and CS-2 of the Q.1200 recommendation series. The 
European Telecommunications Standards Institute (ETSI) specifies INSs in its Core 
Intelligent Network Application Part (INAP). The 3 GPP specifies INSs for its Customized 

30 Applications for Mobile Network Enhanced Logic (CAMEL) technology, Phases 1 , 2, 3 as 
defined in the GSM Technical specification versions 02.78, 03.78 and 09.78 and in the 
Third Generation (3G) technical specification versions 22.078, 23.078 and 29.078. The 
American National Standards Institute (ANSI) specifies INSs in its Advanced Intelligent 
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Network (AIN) specifications versions 0.1 and 0.2. The 3GPP2 specifies INSs in its 
Wireless Intelligent Network (WIN) Phase 2 version N.S004 technical specification. All of 
the above versions and specifications for INS technologies are hereby incorporated by 
reference in their entireties. 

5 For illustrative purposes, INSs, particularly prepaid charging, will be described 

below primarily in the context of the traditional implementation in which an SCM module is 
consulted, and more specifically will be described primarily in relation to CAMEL 
technology and in relation to GSM, GPRS, and GSM/GPRS networks. 
Intelligent Network Services for Circuit-switched Voice Services 

10 Fig. 6 is an example of a an NSS 110 of an MCN that is capable of providing 

package-switched services, circuit-switched voice services and one or more INSs for circuit- 
switched voice services. As used herein, a "circuit-switched INS" is an INS configured for 
circuit-switched voice services. 

The NSS 1 10 may include an SIR 150, one or more SCF modules 148, one or more 

1 5 CSMs (1 34a, 1 34b), one or more PSMs, including PSM 1 36a, and one or more PIMs, 

including PIM 144a. Each of these network elements may be configured with functionality 
that is at least similar to functionaUty of network elements of the same name described 
above in relation to NSS 10 of Fig. 5, and also may be configured with additional 
functionality as follows. The CSM 134a may be configured to exchange call packets 157 

20 with a WASC of a WAS, and exchange call packets 159 with nodes of other 

communications networks, for example a PSTN. CSM 134a may be configured to 
communicate packets with such external networks directly or may be configured to use 
another CSM 134b to communicate with such external networks. As used herein, a "call 
packet" is a communication unit exchanged between modules of an MCN as part of a 

25 circuit-switched voice service (e.g., a telephone call). 

To implement one or more INSs on the NSS 1 10, the SCF module 148 may be 
configured with circuit-switched INS functionality 149 that defines and controls one or 
more INSs, for example, prepaid charging. Further, the CSM 134a may include a Service 
Switching Function (SSF) module 151 configured to exchange communications (e.g., 

30 packets) with the SCF module 148 to implement the one or more INSs. As used herein, an 
"SSF module" is a module (e.g., software, hardware, firmware or any combination thereof) 
residing on a node of an MCN that is configured to at least assist in implementing one or 
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more INSs by exchanging communications (e.g., packets) with one or more SCF modules 
that define and control the one or more INSs. 

To implement one or more INSs, the SSF module 151 and the SCF module 148 may 
be configured to exchange one or more circuit-switched-INS packets 147. As used herein, a 
5 "circuit-switched-INS packet" is a packet exchanged between network elements to 

implement a circuit-switched INS. Specifically, the SSF module 151 may be configured to 
communicate with the SCF module 148 in response to one or more triggering events, such 
as the initiation of a telephone call, the answering of a telephone call, or the termination of a 
telephone call (i.e., hanging up). 

10 The SIR 1 50 may include administration, location and non-INS information 1 52 for 

a subscriber, as described above in relation to Fig. 5. In addition, the SIR 1 50 may include 
subscriber circuit-switched-INS infonnation 154. For each subscriber, this information 154 
may include information about one or more circuit-switched INSs to which the subscriber is 
registered. For each such circuit-switched INS to which the subscriber is registered, the 

1 5 information 1 54 may include an identity of the SCF module to be used to implement the 
INS and the triggering events in response to which an SSF should contact the appropriate 
SCF module. 

Accordingly, when a subscriber attaches to the MCN to which the NSS 1 10 belongs, 
the CSM 134a may download from the SIR 150 the subscriber information 155 which 

20 includes the subscriber circuit-switched INS information 154. Subsequently, in response to 
a triggering event, the SSF module 151 may initiate communications with the SCF module 
148, and request and receive instructions and information relating to the triggering event. 

For example, SSF module 151 may be configured to communicate with the SCF 
module 148 to implement prepaid charging for a circuit-switched voice service such as the 

25 maintenance of a telephone call connection. In response to the CSM 1 34A detecting the 
answering of the telephone call by a subscriber, the SSF module 151 may send a circuit- 
switched INS packet 147 to SCF module 148 to request INS instructions and information for 
the telephone call. The circuit-switched INS functionality 149 may determine the 
instructions and information, and the SCF module 148 may send a circuit-switched INS 

30 packet 147 including such instructions and information to the SSF module 151. 

If the INS is prepaid charging, a packet 147 sent by the SCF module 148 may 
include information for implementing prepaid charging. The SSF module 151 may be 
configured to receive such information and to implement prepaid charging accordingly. 
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Further, the SSF module 151 may be configured to communicate with the SCF module 148 
throughout the call in response to one or more other triggering events. 

Depending on the type of MCN, the NSS 1 10 may be configured to implement one 
or more INSs in accordance with one or more of the INS technologies discussed above. For 
5 example, if the MCN is a GSM, the SIR 150 is an HLR and the CSM 134A is an MSG, then 
the SIR 150, the CSM 134A and the SCF module 148 may be configured to implement one 
or more INSs in accordance with CAMEL, for example, in accordance with CAMEL Phase 
1 or 2. Further, the SSF module 151 may communicate with the SCF module 148 in 
accordance with the CAMEL Application Part (CAP) protocol on top of the signaling 

1 0 system 7 (SS7 protocol) in accordance with CAMEL Phase 1 or 2. 

The PSM 136A may be configured to exchange session packets 1 58 with a WASC 
of a WAS and exchange session packets 160 with a PIM 144A, which exchanges session 
packets 162 with one or more nodes of one or more PDNs. As used herein, a "session 
packet" is a communication unit exchanged between modules of an MCN as part of a 

15 session. 

Although PSM 136A may be configured to download subscriber information 156, 
for example, in response to a subscriber attaching to the MCN to which the NSS 110 
belongs, and to switch session packets 158 and 160, PSM 136 is not configured to 
communicate with SCF module 148 to implement one or more packet-switched INSs. As 
20 used herein, a "packet-switched INS" is an INS configured for packet-switched services. 

Further, SIR 150 does not include subscriber packet-switched INS information, and 
SCF module 148 does not include any packet-switched INS functionality. Accordingly, 
NSS 1 10 is not configured to provide one or more packet-switched INSs. 
Intelligent Network Services for Packet- Switched Services 
25 To implement one or more packet-switched INSs on an NSS, it is known to 

configure an NSS 210 as illustrated in Fig. 7. NSS 210 may include an SIR 250, one or 
more SCF modules 248, a PSM 236A and a PIM 144A. NSS 210 also may include CSMs 
134A and 134B (not shown). 

Each of these network elements may be configured with functionality that is at least 
3 0 similar to functionality of network elements of the same name described above in relation to 
NSS 110 of Fig. 6, and also may be configured with additional functionality as follows. The 
PSM 23 6A may be configured to exchange session packets 158 with a WASC of a WAS, 
and exchange session packets 160 with PIM 144A, which may be configured to 
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communicate session packets 162 with external networks such as a PDN. Further, the PSM 
236A may include an SSF module 262 configured to exchange communications (e.g., 
packets) with the SCF module 248 to implement the one or more INSs. 

The SCF module 248 may be configured with functionality at least similar to 
5 functionality of SCF module 148, described above in relation to Fig. 6, and in addition may 
include packet-switched INS functionality 249 that defines and controls one or more INSs, 
for example, prepaid charging for packet-switched services. 

To implement one or more INSs, the SSF module 262 and the SCF module 248 may 
be configured to exchange one or more packet-switched INS packets 260. As used herein, a 

1 0 "packet-switched-INS packet" is a packet exchanged between network elements to 

implement a packet-switched INS. Specifically, the SSF module 262 may be configured to 
communicate with the SCF module 248 in response to one or more triggering events, 
including the initiation of a session, and the termination of a session. 

The SIR 250 may be configured with at least similar information to the information 

15 of SIR 1 50, described above in relation to Fig. 6, and in addition, may include subscriber 
packet-switched-INS information 254. For each subscriber, this information 254 may 
include information about one or more packet-switched INSs to which the subscriber is 
registered. For each such packet-switched INS to which the subscriber is registered, the 
information 254 may include an identity of the SCF module to be used to implement the 

20 INS and the triggering events in response to which an SSF should initiate communications 
with the appropriate SCF module. 

Accordingly, when a subscriber attaches to the MCN to which the NSS 210 belongs, 
the PSM 236A may download from the SIR 250 the subscriber information 256 which 
includes the subscriber packet-switched INS information 254. Subsequently, in response to 

25 a triggering event, the SSF module 262 may initiate communications with the SCF module 
248, and request and receive instructions and mformation relating to the triggering event. 

For example, SSF module 262 may be configured to communicate with the SCF 
module 248 to implement prepaid charging for a packet-switched service such as the 
maintenance of a session. In response to the PSM 23 6 A detecting a response by a 

3 0 subscriber to a request to establish a session, the SSF module 262 may send a packet- 
switched-INS packet 260 to SCF module 248 to request INS instructions and information 
for the session. The packet-switched INS functionality 249 may determine the instructions 
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and information, and the SCF module 248 may send a packet-switched-INS packet 260 
including such instructions and information to the SSF module 262. 

If the INS is prepaid charging, the packet 260 sent by the SCF module 248 may 
include information for implementing prepaid charging. The SSF module 262 may be 
5 configured to receive such information and to implement prepaid charging accordingly. 
Further, the SSF module 262 may be configured to communicate with the SCF module 248 
throughout the session in response to one or more other triggering events. 

Depending on the type of MCN, the NSS 210 may be configured to implement one 
or more INSs in accordance with one or more of the INS technologies discussed above. For 

10 example, if the MCN is a GSM, the SIR 250 is an HLR and the PSM 236A is a SGSF 
module, then the SIR 250, the PSM 236A and the SCF module 248 may be configured to 
implement one or more INSs in accordance with CAMEL, for example, in accordance with 
CAMEL Phase 3. Further, the SSF module 262 may communicate with the SCF module 
248 in accordance with the CAMEL Application Part (CAP) protocol oh top of the SS7 

1 5 protocol in accordance with CAMEL Phase 3 . 

Establishing a Session For a Roaming Subscriber of an MCN 
A typical methodology for establishing a session between a roaming subscriber and a 
node of a PDN will now be described with reference to Fig. 5. As used herein, a "roaming 
subscriber" is a subscriber who is accessing network services from outside of his home 

20 MCN (i.e., from a visited MCN). A subscriber's home MCN is the MCN from which the 
subscriber obtains a mobile service subscription. For example, a subscriber may obtain a 
mobile service subscription from a MCN operator in New England. As the subscriber . 
travels on business in California, the subscriber may access network services provided by an 
MCN in California (the visited MCN), which may have a roaming arrangement (i.e., 

25 agreement) with his home MCN in New England. Such a roaming agreement may specify, 
among other things, what type of network services the subscriber is allowed and not allowed 
to access, and how the subscriber will be billed for the network services the subscriber 
accesses while roaming in the California MCN. For example, the subscriber may be barred 
from making international calls while roaming in the California MCN. 

30 If a subscriber whose home MCN is MCN 2 (i.e., the home MCN) roams into 

another MCN 4 (i.e., the visited MCN), the subscriber's MT may communicate with the 
visited MCN 4 to make telephone calls or establish sessions. The subscriber's MT may 
initiate an attach (e.g., when the MT is powered on) by sending an attach request to visited 
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MCN 4. In response to receiving the attach request, a PSM 54 of visited MCN 4 may 
determine the location of the SIR 50 that stores information about the roaming subscriber. 
For example, the attach request may include the international mobile subscriber identity 
(IMSI) of the subscriber by which the PSM 54 may determine the location of the SIR 50. 
5 The PSM 54 then may communicate with the SIR 50 to retrieve information about the 
subscriber. 

If the roaming subscriber wants to access a node 66 on PDN 6 A, the subscriber 
initiates establishment of a data session with the node 66 through visited MCN 4, e.g., 
through the PSM 54. For example, the MT of the roaming subscriber may initiate the 

1 0 establishment of a PDP context on a PIM that provides an interface to PDN 6A. 

As illustrated in Fig. 5, the home MCN 2 of the roaming subscriber may include PIM 
44A (the home PIM) that interfaces to PDN 6A, and visited MCN 4 also may include a PIM 
52 (the visited PIM) interfacing to PDN 6A. Thus, to establish a session between the MT of 
the roaming subscriber and node 66, it should be determined which PIM, home PIM 44A or 

1 5 visited PIM 52, is to be used to establish the session. 

Accordingly, in SIR 50 (i.e., the home SIR), an entry for the roaming subscriber may 
include a field specifying whether to use home PIM 44A or a visited PIM to establish a 
session to a node of PDN 6A when the subscriber is roaming in MCN 4. Thus, during the 
attach process as the subscriber is roaming in the MCN 4, the PSM 54 may request profile 

20 information for the roaming subscriber from SIR 50. In response, the SIR 50 may send 

PSM 54 information including a value stored in such a field, and the PSM 54 may determine 
from such value which PIM to use to establish a session with node 66 of PDN 6A-home 
PIM 44A or visiting PIM 52. PSM 54 then may use the determined PIM to establish a 
session with node 66. 

25 

SUMMARY 

A problem with existing communications networks, including MCNs, is that a 
subscriber does not have the ability to add value to an account for a multimedia service 
while the service is being provided so that the duration that the services is provided is 
30 extended. 

Another problem with communications networks is that communications networks 
that are capable of enabling a subscriber to top-up an account for a voice service while the 
voice service is being provided are typically limited to the following technique: playing a 
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voice prompt (e.g., a VRU), possibly putting the non-calling or non-billed party on hold, and 
allowing the calling or billed party to use DTMF tones to enter a new top-up account 
number or enter a credit card charge for the top-up amount. Such technique is referred to 
herein as "the known voice service top-up technique". 
5 Another problem with communications networks is that, although some 

communications networks are capable of notifying a subscriber that a threshold amount of a 
voice service has been reached during provisioning of the voice service and enabling a 
subscriber to top-up an account for the voice service during the provisioning such 
capabilities are not available for multimedia services. In an illustrative embodiment of 

10 the invention, a session is provided between a user terminal used by a subscriber and a 

server of a communications network providing a service to the subscriber, where the session 
involves the exchange of at least one of data content and video content, and the subscriber 
has a account balance for the service. A threshold for the service is maintained during the 
session, the threshold corresponding to the account balance. An amount of the service used 

1 5 during the session is metered, and it is determined that the threshold has been reached. The 
subscriber is notified through the user terminal that the threshold has been reached, and the 
subscriber is enabled an opportunity to add to the account balance using the user terminal. 

This embodiment may be implemented as a computer program product that includes 
a computer-readable medium and computer-readable signals stored on the computer- 

20 readable medium, which signals define appropriate instructions. These instructions, as a 
result of being executed by a computer, instruct the computer to perform the acts described 
above for this illustrative embodiment. 

In another illustrative embodiment, a system for providing a session between a user 
terminal used by a subscriber and a server of a communications network providing a service 

25 to the subscriber is provided, where the session involves the exchange of at least one of data 
content and video content, and the subscriber has a account balance for the service. The 
system comprises a session support module to maintaining a threshold for the service during 
the session, the threshold corresponding to the account balance, to meter an amount of the 
service used during the session, and to determine that the threshold has been reached. The 

3 0 system also comprises means for notifying the subscriber through the user terminal that the 
threshold has been reached and means for enabling the subscriber an opportunity to add to 
the account balance using the user terminal. 

In another illustrative embodiment, the subscriber is enabled an opportunity to add to 
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a balance for a service provided during a session between a user terminal used by a 
subscriber and a server of a communicatioiis network providing the service to the 
subscriber. Session content transmitted by the server to the user terminal as part of the 
session is buffered while enabling the subscriber the opportunity to add to the account 
5 balance. 

In an aspect of this embodiment, after the subscriber has added to the account 
balance, the buffered session content is transmitted to the user terminal. 

In another aspect of this embodiment, values for one or more session states for the 
session from a time at which the threshold was reached are maintained, while enabling the 
10 subscriber the opportunity to add to the account balance. 

In yet another aspect of this embodiment, after the buffered content has been 
transmitted to the user terminal, the session is restored using the values suspended from 
when die threshold was reached. 

This embodiment may be implemented as a computer program product that includes 
15 a computer-readable medium and computer-readable signals stored on the computer- 
readable medium, which signals define appropriate instructions. These instructions, as a 
result of being executed by a computer, instruct the computer to perform the acts described 
above for this illustrative embodiment. 

In another embodiment, a system for enabling the subscriber an opportunity to add to 
20 a balance for a service provided during a session between a user terminal used by a 

subscriber and a server of a communications network providing the service to the subscriber 
is provided. The system comprises means for buffering session content transmitted by the 
server to the user terminal as part of the session while enabling the subscriber the 
opportunity to add to the account balance. 
25 In another embodiment, a subscriber is notified that a threshold amount of service 

corresponding to an account balance for a service has been reached during a session 
between a user terminal used by a subscriber and a server of a communications network 
providing the service to the subscriber. The session involves the exchange in a first format 
of at least one of video content and audio content. The subscriber is notified that the 
3 0 threshold has been reached as part of the session using the at least one of video content and 
audio content formatted in the first format. 

This embodiment may be implemented as a computer program product that includes 
a computer-readable medium and computer-readable signals stored on the computer- 
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readable medium, which signals define appropriate instructions. These instructions, as a 
result of being executed by a computer, instruct the computer to perform the acts described 
above for this illustrative embodiment. 

In another embodiment, a system for notifying a subscriber that a threshold amount 
5 of service corresponding to an account balance for a service has been reached during a 
session between a user terminal used by a subscriber and a server of a communications 
network providing the service to the subscriber is provided. The session involves the 
exchange in a first format of at least one of video content and audio content, and the system 
comprises means for notifying the subscriber that the threshold has been reached as part of 
1 0 the session using the at least one of video content and audio content formatted in the first 
format. 

Other advantages, novel features, and objects of the invention will become apparent 
from the following detailed description of the invention when considered in conjunction 
with the accompanying drawings, which are schematic and which are not intended to be 
1 5 drawn to scale. In the figures, each identical or nearly identical component that is illustrated 
in various figures is represented by a single numeral. For purposes of clarity, not every 
component is labeled in every figure, nor is every component of each embodiment of the 
invention shown where illustration is not necessary to allow those of ordinary skill in the art 
to understand the invention. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram illustrating an example a typical billing system for 
providing postpaid voice services; 

Fig. 2 is a block diagram illustrating a typical billing system for providing prepaid 
25 voice services; 

Fig. 3 is a block diagram illustrating an example of a typical communications 
network including a mobile communications network; 

Fig. 4 is a block diagram illustrating an example of a typical wireless access sub- 
network of a mobile communications network; 
3 0 Fig. 5 is a block diagram illustrating an example of a typical network services sub- 

network of a mobile communications network; 
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Fig. 6 is a block and data flow diagram illustrating an example of a typical network 
services sub-network configured to implement Intelligent Network Services for circuit- 
switched voice services; 

Fig. 7 is a block and data flow diagram illustrating an example of a typical network 
5 services sub-network configured to implement Intelligent Network Services for packet- 
switched services; 

Fig. 8 is a block diagram illustrating an example of a mobile communications 
network configured to implement Intelligent Network Services and top-up/Pop-up for 
packet-switched services; 
10 Fig. 9 is a block diagram illustrating an example of a PDP context profile data 

structure; 

Fig. 1 0 is a block diagram illustrating an example of an APN profile data structure; 
Fig. 1 1 is a flow chart illustrating an example of a method of implementing an 
Intelligent Network Service and Top-up/Pop-up for a packet-switched service on a module 
15 of a mobile communications network; > 

Figs. 12A-12B are a flow chart illustrating an example of a method of implementing 
prepaid charging and top-up/Pop-up for a packet-switched service on a module of a mobile 
communications network; 

Fig. 13 is a block diagram illustrating an example of PDP context access information 
20 for accessing a PDP context profile; 

Fig. 14 is a block diagram illustrating an example of an initializing packet for 
initializing an INS; 

Fig. 15 is a block diagram illustrating an example of prepaid charging information 
for a service; 

25 Fig. 16 is a block diagram illustrating an example of a prepaid charging report for a 

service; 

Fig. 17 is a block diagram illustrating an example of a system to enable a subscriber 
to top-up an account while the service is being provided; and 

Fig. 18 is a flow chart illustrating an example of a method for enabling a subscriber 
30 to top-up an account while the service is being provided. 



WO 2002/101624 PCT/LS2002/017492 
-23- 

DET AILED DESCRIPTION 
Although some embodiments of the invention described below are described 
primarily in relation to mobile communications networks (MCNs), the systems and methods 
described herein are not limited thereto, but may be applied to other types of 
5 communications networks, including landline communications networks. 

It is to be appreciated that any of the methods, techniques, systems and operating 
structures of the present disclosure may be embodied in a wide variety of forms and modes, 
some of which may be quite different than those disclosed. For example, although several 
embodiments are described primarily in the context of providing services for mobile 
1 0 terminals, these embodiments are not limited as such, as such embodiments may apply to 
prepaid charging for audio, video and multimedia services delivered via any access method 
(including fixed wireless, dial up, optical, et al). The specific structural and functional 
details disclosed herein are merely representative. 

Although several embodiments of the invention described below are described 
1 5 primarily in relation to implementing prepaid charging, the systems and methods described 
herein are not limited thereto, but may be applied to other Intelligent Network Services 
(INSs), for example, the INSs described above. Further, as described above, although INSs 
are primarily described below as being implemented by exchanging communications with 
an SCF module, an INS is not limited to such implementations, as a network element such 
20 as a CSM or PM may be configured to implement one or more INSs without consulting an 
SCF module or any other network elements, or by consulting one or more other network 
elements in addition to or as an alternative to consulting an SCF module. Such network 
elements may reside internal to the NSS of an MCN, or external to the NSS, for example, on 
a corporate LAN or the Internet. 
25 Further, although several embodiments of the invention described below are 

described in relation to packet-switched services, it should be appreciated that such 
embodiments may be implemented for circuit-switched services as well. 

In an embodiment of the invention, a subscriber of a communications network is 
enabled (e.g., by a node of the network) to top-up an account for a multimedia service 
30 provided on the communications network while the seivice is being provided. As described 
above, a "multimedia service" as used herein is a service that includes an exchange of data 
content and/or video content between two or more nodes of a communications network, and 
may include the exchange of any combination of video content, audio (e.g., voice) content 
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and data content. Thus, a service that exchanges only voice content is not a "multimedia 
service" as used herein. 

It should be appreciated that multimedia services may involve the exchange of 
different types of data content, video content, audio content and combinations thereof, 
5 including bulk data transfers such a file transfer using the File Transfer Protocol (FTP), 

transactional data transfers, persistent streaming data, multi-player gaming content, digitized 
video, and multimedia conferencing content. Thus, in another aspect of the invention, the 
unique characteristics of different types of media, such as those described immediately 
above, may be taken into account when considering the notification process and top-up 

1 0 process to be invoked when a threshold is reached. 

The subscriber's account for a service may be any of a variety of types of accounts, 
for example, a prepaid account where a subscriber has a prepaid balance for a service and a 
postpaid account where a subscriber may have a spending limit (i.e., a credit limit) for a 
service. Such spending limit may be imposed by a provider of a service or operator of a 

1 5 communications network or may be defined and possibly changed by the subscriber. Thus a 
subscriber may be able to control the amount the subscriber is billed for a service. Although 
several embodiments are described below in terms of enabling a subscriber to top-up a 
prepaid balance, such description may be applied analogously to enabling a subscriber to 
change a spending limit, which is intended to fall within the scope of the invention. 

20 As will be discussed in more detail below, an account balance may be converted into 

a threshold amount of service. As used herein, a "prepaid threshold" is a threshold 
converted from a prepaid balance and a "spending threshold" is a threshold converted from 
a spending limit. 

In another embodiment of the invention, real-time prepaid charging is applied to a 
25 multimedia service being provided to a subscriber of a communications network. As used 
herein, "real-time" prepaid charging for a service means prepaid charging for the service 
where, during initiation of a session for the service, a subscriber's prepaid balance for the 
service is converted into a threshold amount of service, and the amount of service consumed 
by the subscriber is metered and compared to the threshold (or an amount of service derived 
30 therefrom) while the service is being provided. Such threshold amount may be a period of 
time and the amount of service compared to the period may be a duration of the service, or 
the threshold amount may be a count and the amount of service compared to the count may 
be a number (i.e., volume) of information units exchanged during the service. 
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In an aspect of real-time prepaid charging, both a count and a time period may be 
determined from the prepaid balance, and the number of information units exchanged during 
the service and the duration of the service may be compared against the count and time 
period, respectively. In. such aspect, further processing may be defined to be performed if 
either and/or both thresholds are reached. 

In another embodiment, a subscriber of a communications network may be notified 
of a threshold amount of service being reached while the service is being provided using the 
same session as is being used to provide the service (in-band) or using a different session 
(out-of-band). In an aspect of being notified out-of-band, the out-of-band notification may 
be sent along some or different transport path than the path on which service packets are 
exchanged with tire user terminal to provide the service. Further, a subscriber may be 
notified of a threshold being reached using a Short Message Service (SMS) by sending an 
SMS message to the subscriber. 

In another embodiment, a subscriber of a communications network may be enabled 
to top-up a service account while the service is being provided using the same session as is 
being used to provide the service (in-band) or using a different session (out-of-band). 

In an aspect of enabling to top-up a service, top-up packets may be sent along a same 
or different transport path than the path on which service packets are exchanged with the 
user terminal to provide the service. 

In an embodiment, to notify the client that a threshold for a service has been reached 
and/or to enable the client to top-up, either in-band or out-of-band sessions may be used 
based on any of a number of factors, including a characteristic of the session in progress 
implementing the service, the capabilities of the user terminal, the capabilities of the 
application and application server providing the service, or any combination thereof. 

In an embodiment, a session for providing a multimedia service is implemented 
using a multimedia control protocol capable of controlling (e.g., initiating, maintaining and 
terminating) a session that includes the exchange of multimedia content, including audio, 
video, data or any combination thereof. For example, such protocol may be the Session 
Initiation Protocol (SIP). The SIP protocol is defined in RFC 2543, SIP: Session Initiation 
Protocol by Internet Engineering Task Force (IETF) as of October 26, 1999. Other such 
multimedia control protocols may be used, including Telephony Application Programming 
Interface (TAPI), Telephony Server Application Programming Interface (TSAPI), H.323, 
Media Gateway Control Protocol (MGCP), MEGACO, Open Services Architecture (OSA), 
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PARLAY, Java Advanced Intelligent Network (JAIN), and ad hoc IP-based protocols. In an 
aspect of this embodiment, the subscriber is notified in-band that a threshold amount of 
service has been reached and/or enabled to top-up in-band using a multimedia control 
protocol 

5 In an embodiment of the invention, a subscriber of a communications network is 

enabled (e.g., by a node of the network) to top-up an account for a service provided on the 
communications network while the service is being provided using a technique other than 
the known voice service top-up technique described above. In one embodiment, a service 
on a user terminal is suspended while the top-up opportunity is provided. For example, a 

1 0 module of a communications network (e.g., a PIM and/or a service support module 
described below) may maintain session states during the session and may maintain the 
values of the session states at the time at which the threshold is reached. Such module may 
serve as a proxy for the user terminal and/or a server and be responsive to asynchronous 
in/band or out of band control messages, for example, hi accordance with a multimedia 

1 5 control protocol. Implementation of such maintenance, proxying and receiving of 

asynchronous messages may vary based on the media content exchanged as part of the 
session, protocol types used to exchange the media content and techniques being utilized to 
suspend the session. Thus, such module may be capable of receiving a control message that 
causes it to begin acting as a proxy towards a user terminal and/or a server. In another 

20 embodiment, the user terminal itself may be configured with intelligence (e.g., an agent) to 
maintain state information for a service and exchange communications with network 
modules until an account for the service is topped-up. Other techniques may be used. 

Such suspension of service allows a top-up opportunity to be afforded without 
affecting the service application or applications that are transmitting data at the point in time 

25 that a threshold amount of service is reached. This capability is useful in any number of 
circumstances, for example, in multi-player gaming contexts where a player may be 
interested in continuing a current session without having to restart the session as a result of a 
top-up being performed, or if a large file is being transferred to a subscriber as part of an 
application when a threshold is reached. 

30 In another example of this embodiment, service content transmitted from the service 

provider to the subscriber on the subscriber's user terminal may be buffered (e.g., cached) in 
a buffer while the subscriber is provided the opportunity to top-up the account. After the 
subscriber tops-up or after the opportunity to top-up has elapsed, the buffered content then 
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may be transmitted to the user terminal. While such buffered content is being transmitted 
from the buffer to the user terminal, any additional service content transmitted from the 
service provider to the end station may continue to be cached until the buffer is empty, at 
which point any additional transmitted service content may be transmitted (i.e., forwarded) 
5 directly to the user terminal without being buffered. In this example, the application 
providing the service may remain unaware that the subscriber has reached a threshold for 
this service, and thus continually transmit content while the subscriber is enabled the 
opportunity to top-up. Such technique is useful in a situation where it is not desirable to 
terminate a session when large volumes of content (e.g., a larger data, video or multimedia 

1 0 file) are being downloaded such that the large content is lost and would have to be re- 
transmitted after another session is established (perhaps after paying a bill or adding more 
value to a prepaid account). 

In another example of this embodiment, while the subscriber is being enabled to top- 
up a prepaid account for a service, a different billing method, for example, postpaid 

1 5 charging, is applied for the service until the subscriber tops-up or until the opportunity to 
top-up has elapsed. 

In another example of this embodiment, as a subscriber is being enabled an 
opportunity to top-up, another service (e.g., a "free" Internet service) is provided for the 
subscriber. 

20 In another embodiment of the invention, when a threshold amount for a prepaid 

service is reached, a different billing method, for example, postpaid charging, is applied for 
the service. As used herein, a "prepaid service" is a service for which a subscriber has 
subscribed for prepaid charging, or a service for which prepaid charging is applied. 

One embodiment of this disclosure uses a unique addressing scheme that allows one 

25 ore more combinations of a subscriber, a session and a service to be individually identified. 
For example, an address of a user terminal can underpin a prepaid threshold notification and 
top-up process, and allow coordination between application and network layers through an 
Application Programming Interface. This embodiment is beneficial to effect the ability to 
control a session asynchronously, by providing an agreed-upon mechanism that allows a 

30 service module that initiates the top up request (e.g, the server providing the service, an SCP 
module, and SCF module, a service support module) to uniquely identify the subscriber, 
session(s) and service(s) that may be affected by this top up action. 
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Another embodiment provides the ability to top-up an electronic account for a 
service while preserving the security of access to the electronic account by accessing the 
account indirectly by mapping a subscriber ID (e.g., IMSI), session ID (e.g., PDP context 
ID) and a service ID (e.g, an APN). Such an addressing schema does not betray the identity 
5 of the subscriber or the electronic account, while allowing the electronic account to be 

topped up. Thus, the true identities of a subscriber (the subscriber's IMSI for example) may 
be hidden from the module (e.g., server) that initiated the top up action, by avoiding the 
need to advertise the subscriber, session or service information while preserving the ability 
for the top up action to be performed. Although such addressing scheme serves as a security 
10 measure, it also may protect vital identity information from being displayed to the outside 
world. 

In another embodiment of this invention, a network operator (or another entity that 
provides the ability to implement topping-up for services) and a service provider may 
contract an agreement ("service agreement") that defines a service to be provided to 

15 subscribers. Such agreement may specify the type of charging to be used for the service 
(postpaid, flat fee, real-time prepaid, hot billing, etc) and various notification and top-up 
parameters for the service. One or more data structures (e.g., APN profiles, described 
below) stored on a tangible medium may persist the agreements and may be indexed by a 
service ID (e.g., APN). 

20 In another embodiment, a subscriber may contract an agreement ("subscriber 

agreement") with a network operator and/or a service provider that defines a service to be 
provided to the subscriber. Such agreement may specify the type of charging to be used for 
the service (postpaid, flat fee, real-time prepaid, hot billing prepaid, etc) and various 
notification and top-up parameters for the service. One or more data structures (e.g., PDP 

25 context profiles, described below) stored on a tangible medium may persist the agreements 
and may be indexed by a combination of a subscriber ID (e.g., and an IMSI) and a service 
ID (e.g., APN) or by using a PDP Context ID. 

In an embodiment, when a session is initiated for a subscriber for a service, values 
from a service agreement and a subscriber agreement for the service are combined. For 

30 parameters (e.g., type of prepaid charging, top-up method) for which each agreement has a 
value defined, one value may be defined to take precedence over the other or the values may 
be combined in some fashion. 
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In another embodiment, if a network operator already provides a prepaid charging 
account for voice services, the same prepaid account may be used for providing prepaid 
charging for multimedia services, whether circuit-switched or packet-switched. Thus, 
extensive investments that already have been made in systems for implementing voice 
5 services, for example, those systems used to create and distribute prepaid cards and/ or top-up 
cards, can also be used for multimedia services. 

It is to be appreciated that the ability to allow subscribers to top-up and thus continue 
a multimedia service is a value-added service that encourages higher spending for services 
by subscribers. Thus, it may be desirable for a network operator to enable the ability to top- 
1 0 up for multimedia services for its subscribers, so that additional revenues may be realized. 
For example, the network operators may charge subscribers or service providers for the 
added functionality, contract with service providers to share revenues derived from the 
added functionality, or do any combination thereof. 



1 5 thus continue a service, including multimedia services or voice services using a technique 
other than the known voice service top-up technique described above adds value to any 
service provided on a communications network and thus encourages higher spending for 
such services by subscribers. Thus, it may be desirable for a network operator to enable the 
ability to top-up for services using any of the several new techniques described herein so 

20 that additional revenues may be realized. 
Examples 



Although implementing prepaid charging and Pop-up/Top-up is described below in 
relation to Figs. 8-17 primarily in the context of packet-switched services, such illustrative 
embodiment is not meant to limit the scope of the invention, as prepaid charging and Pop- 
25 up/Top-up may be performed for other types of services as well, for example, services 
implemented using a virtual circuit technology such as Asynchronous Transfer Mode 
(ATM) technology. 

Although implementing Pop-up/Top-up is described below in relation to Figs. 8-17 
primarily in the context of prepaid charging, such illustrative embodiment is not meant to 
30 limit the scope of the invention, as Pop-up/Top-up may be performed for other types of 
charging, for example, postpaid charging as well. For postpaid charging, a subscriber's 
account may have a spending limit (as opposed to a prepaid balance). This spending 
threshold may be converted to a spending threshold (as opposed to a prepaid threshold) that 



Further, it should be appreciated that the ability to allow subscribers to top-up and 
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may be compared against a metered duration of a service or a metered count of information 
units exchanged during the session. 

Fig. 8 illustrates an example of anNSS 310 including a PIM 344A (e.g., a GGSF 
module) for implementing one or more packet-switched INSs. NSS 310 may include any of 
an SIR 150, an SCF module 148, aPSM 136A, PIM 344A and a subscriber services register 
(SSR) 370. NSS 310 also may include one or more CSMs, for example, CSM 34A or 134A 
(not shown) as well as other network elements. Each of the network elements of NSS 310 
may be interconnected with other network elements by any of a variety of types of 
transmission media, including cables, wires, optical fibers, air, and combinations thereof. 
Other network elements may include switching elements, for example, transceivers, 
repeaters, switches, routers, bridges, and combinations thereof. 

NSS 310 may be part of any of a variety of types of MCNs described above, for 
example, a GPRS network, a GSM/GPRS network, a UMTS network, any type of CDMA 
networks (e.g., cdmaOne, cdma2000, etc.), a Wireless PAN, for example, Bluetooth or a 
wireless PAN in accordance with IEEE 802. 15, a WLAN, for example, HiperLan 2 or a 
WLAN in accordance with IEEE 802.11 (e.g., 802.11b (Wi-Fi), 802.1 la and 802.11g), or 
any other type of MCN. 

SIR 150, SCF Module 148 and PSM 136A may be configured similar to, and 
possibly the same, as described above in relation to NSS 110 of Fig. 6. The PSM 136A may 
be configured to exchange session packets 158 with a WASC of a WAS, and exchange 
session packets 160 with PIM 344A, which may be configured to communicate session 
packets 162 with external networks such as PDN 6A. In an embodiment, PIM 344A is a 
WN 1200 Intelligent Support Node available from WaterCove Networks, Inc. of 
Chelmsford, Massachusetts. 

SSF module 362 may be configured to exchange packets with SIR 150 in accordance 
with any of one or more signaling transport technologies, which may incorporate 
combinations of one or more protocols, for example, SS7 signaling transport technologies 
(e.g., MAP over Transaction Capabilities Application Part (TCAP) over Signaling 
Connection Control Part (SCCP) over Message Transfer Part (MTP)), SS7 over IP signaling 
transport technologies (e.g., as described in IEFT Request For Comments (RFC) 2719 
Framework Architecture for Signaling Transport, IP signaling transport technologies (e.g., 
GTP over User Datagram Protocol (UDP) over IP, or Radius over TCP over IP), or other 
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The SCF module 148 may include circuit-switched INS functionality 149 that 
defines and controls execution of one or more INSs, for example, prepaid charging, for 
circuit-switched voice services. For prepaid charging, the circuit-switched INS functionality 
149 may include subscriber prepaid charging information such as an amount of service 
5 currently prepaid for by a subscriber. For example, a subscriber may have prepaid $4.00 for 
20 minutes of service. 

To implement one or more INSs, the SSF module 362 and the SCF module 148 may 
be configured to exchange one or more circuit-switched INS packets 147. Specifically, the 
SSF module 362 may be configured to exchange communications with the SCF module 148 

10 in response to one or more triggering events, such as the initiation of a session, or the 
termination of a session. 

SSF module 362 may be configured to exchange packets with SCF module 148 in 
accordance with any of one or more signaling transport technologies, which may incorporate 
combinations of one or more protocols, for example, SS7 signaling transport technologies 

1 5 (e.g., CAP over TCAP over SCCP over MTP), SS7 over IP signaling transport technologies 
(e.g., CAP over TCAP over S3UA over IP), IP signaling transport technologies (e.g., GTP 
over UDP over IP, or Radius over TCP over IP), or other signaling transport technologies. 

As will be described in more detail below, a circuit-switched INS packet 147 
transmitted from the SCF module 148 or the SSF module 362 may include circuit-based 

20 parameters. Accordingly, the SSF module 362 may include a packet-switched adapter 364 
configured to implement an INS for packet-switched services using circuit-based 
parameters. Such implementation may include exchanging packets with the SCF module 
148 using circuit-based parameters. 

The packet-switched adapter 364 may include a conversion module 366 configured 

25 to convert circuit-based parameters to packet-based parameters and vice versa. For 

example, if the INS is prepaid charging, the conversion module 366 may be configured to 
convert a call period that specifies an amount of time prepaid for by a subscriber into a 
count threshold or a time threshold for a session. The count threshold may serve as a 
threshold for a number of information units (e.g., bytes, kilobytes, packets) transmitted 

30 during a session, as will be described below. The time threshold may serve as a threshold 
amount of time of a session. The conversion module 366 also may be configured to convert 
the count threshold or time threshold back into a call period. Such conversions are 
described below in more detail. 
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In an embodiment, the PDN interface module 344A may be logically and/or 
physically divided into two modules, a service support module 361 and a session support 
module 363. Service support module 361 may be configured to manage coordination 
between session layers and service layers of a service and to assist in implementing INSs, 
5 and thus module 361 may include SSF module 362. Service support module 361 may 

include additional logic to assist implementing services using PDP context profiles and APN 
profiles including handling requests to operate PDP contexts, discussed below in more detail 
in relation to Figs. 9 and 10. 

In an embodiment of NSS 310, one or more service support modules 361 and session 
10 support modules 363 may reside on separate nodes of NSS 3 1 0. 

The session support module 363 may include flow control functionality, session 
control functionality and functionality for metering a session between a subscriber and a 
node of a PDN. 

The session support module 363 may include a metering module 365, which may be 
15 configured to meter a session between a subscriber and a node of a PDN. Metering a 

session may include determining a number of information units (e.g., transactions, packets, 
kilobytes, bytes) exchanged between the subscriber and the PDN node during the session, 
metering a duration of the session or any combination thereof. The SSF module 362 may be 
configured to control such metering and to report the results of such metering to the SCF 
20 module 148. 

PIM 344A (e.g., service support module 361) may be further configured to exchange 
communications with application servers located external to NSS 310, for example, on PDN 
node 66, to establish an initial time or count (i.e., volume) threshold for a service. For 
example, PIM 344A may be configured with one or more application programming 

25 interfaces (APIs) that enable such configuration. Accordingly, PIM 344A may be 

configured to notify an application residing on an application server when a threshold 
amount has been consumed by a session. This ability to associate a service with a session 
and a subscriber may be accomplished by defining one or more elements of NSS 3 10, as 
will be discussed in more detail below. 

30 Further, PIM 344A (e.g., service support module 361) may be configured with one 

more APIs that interface that exchange communications with servers located external to the 
NSS 3 10 to provide the pop-up/top-up capability described in more detail below. Thus, to 
provide a pop-up notification, enable a top-up opportunity and to implement interim 
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operations while the top-up opportunity is being enabled (as described below in more detail 
in relation to acts 819-824 of method 800 and Figs. 17 and 18), PIM 344A may exchange 
communications with one or more application servers. Further, PIM 344A may be 
configured to exchange communications with any applications that may be affected by a 
5 threshold amount corresponding to a subscriber account balance or spending limit being 
reached. Thus, when such a threshold is reached, PIM 344A may send notications to such 
applications. 

Configuring the SSF module 362 with packet-switched adapter 364 as described 
above may obviate a need to configure the SCF module 148 with packet-switched INS 

10 functionality (e.g., functionality 249 described above in relation to Fig. 7) in order to 

implement an INS. For example, if an SCF module 148 is configured to implement prepaid 
charging in accordance with CAMEL Phase 2 for circuit-switched voice services, the SCF 
module 148 does not need to be upgraded or replaced in order to implement prepaid 
charging in accordance with CAMEL Phase 3 for packet-switched services. The packet- 

1 5 switched adapter 364 may be configured to implement the prepaid charging in accordance 
with CAMEL Phase 3 using the CAMEL Phase 2 parameters included in the prepaid 
charging packets transmitted from the SCF module 148. For example, the conversion 
module 366 may be configured to convert the CAMEL Phase 1 or 2 prepaid charging 
parameters (e.g., call period) to CAMEL Phase 3 prepaid charging parameters (e.g., count or 

20 time thresholds), and vice versa. The capability of the conversion module 366 to convert 
CAMEL Phase 3 prepaid charging parameters into CAMEL Phase 2 prepaid charging 
parameters, and vice versa, enables the SSF module 362 to exchange prepaid charging 
packets with the SCF module 148 in accordance with CAMEL Phase 2. 

The SSF module 362 also may be configured to exchange packet-switched-INS 

25 packets with SCF module 1 48 if SCF module 1 48 is configured with packet-switched INS 
functionality. Further, the SSF module 362 may be configured to selectively exchange 
circuit-switched or packet-switched INS packets with SCF module 148, for example, in 
accordance with CAMEL Phase 1, 2 or 3, respectively, depending upon the capabilities of 
the SCF module 148. 

30 Although SSF module 362 has been illustrated in relation to Fig. 8 as being part of 

PIM 344A, alternatively, SSF module 362, including packet switched adapter 364 and 
conversion module 366, may be configured as part of PSM 136A or another network 
element. Further, SSF module 362 may be distributed across a plurality of network 
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elements. Communications exchanged between SSF module 362 and SCF module 148 are 
described in more detail below. 

SSR 370 may include subscriber services information 371. For each subscriber, 
information 372 may include information about one or more services, including subscriber 
5 packet-switched-INS information 372 for packet-switched INSs to which the subscriber is 
registered. For each such packet-switched INS to which the subscriber is registered, 
information 372 may include an identity of the SCF module (e.g., SCF module 148) to be 
used to implement the INS, triggering events in response to which an SSF should initiate 
communications with the appropriate SCF module, and other information. At least some of 
1 0 this other information may be used by the SSF module 3 62 to implement an INS for a 
packet-switched service using circuit-switched INS packets 147 exchanged with SCF 
module 148. 

Subscriber services information 371 also may include information about one or more 
services provided by service providers from servers located external to NSS 310, for 

15 example, on PDN node 66. For example, information 371 may include at least one of a 

subscriber agreement (e.g., a PDP profile data structure 1000) and a service agreement (e.g., 
an APN profde data structure 1 100), each of which is described in more detail below. 

Fig. 9 is a block diagram illustrating an example of a PDP context profile data 
structure 1000 that includes one or more PDP context profiles 1001, each profile 1001 

20 including one or more information elements (IEs). Each profile 1001 may define a 

subscriber's subscription to a specific service, and thus may serve as a link between the 
subscriber's subscription to the MCN and the subscriber's subscription to a service offered 
by the service provider. An APN profile 1101, described below in relation to Fig. 10, 
defines a service agreement between the MCN of NSS 310 and a service provider, values 

25 for which may be overridden or combined with values specified by a PDP context profile 
1001 defined for a specific subscriber. Thus, each profile 1001 includes subscription 
information for a particular subscriber for an APN, from which a PDP context session may 
be generated. Data structure 1000 may be any of a variety of types of data structures, 
including an object, a table, or a plurality of records separated by delimiters. Other types of 

3 0 data structures may be used also. 

The PDP context profile 1000 may include any of: subscriber ID IE 1002, MT ID IE 
1004, PDP context ID IE 1006, PDP type IE 1008, APN IE 1010, QoS profile IE 1012, INS 
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subscription information IE 1013, charging type 1014, calling party number IE 1015, called 
party number IE 1016, charging rate modifier IE 1018, and possibly other IEs. 

The subscriber ID IE 1002 uniquely identifies the subscriber, and may serve as a key 
or index for the PDP context profile 1001 along with APN IE 1010. Depending on the type 
of MCN, the IE 1002 may specify an MSI or another type of unique identifier of a 
subscriber. 

The MT ID IE 1004 identifies the MT (moibile terminal) for which this PDP context 
profile applies. Depending on the type of MCN, the IE 1004 may specify an MSISDN or 
another type of unique identifier of an MT. IE 1006 is a unique identifier for the PDP 
context profile and may serve as a key or index for the PDP context profile 1001 . IE 1008 
identifies the type of PDP, for example, IP or Point-to-Point Protocol (PPP). 

IE 1010 specifies an APN for which the profile 1001 is defined. IE 1010 may serve 
as an index to an APN profile 1101. IE 1012 specifies the quality of service subscribed to 
by the subscriber for this PDP context 

IE 1013 specifies information about one or more INSs subscribed to by the 
subscriber for this PDP context. For example, IE 1013 may include information about 
prepaid charging, including the location of the SCF module to be used to implement prepaid 
charging, for example, an IP address or other type of location identifier of SCF module 148. 

IE 1014 specifies the type of charging subscribed to by the subscriber for this PDP 
context. Types of charging may include, but not be limited to, postpaid charging, flat-rate 
charging, hot billing or real-time prepaid charging. Postpaid charging is a type of charging 
for which a subscriber receives the service first, and then pays for the service periodically, 
for example, monthly. For each session or telephone call across an MCN for postpaid 
charging, an operator generates a Call Detail Report (CDR), and consolidates these CDRs to 
generate the periodic bill. Thus, if a subscriber makes five telephone calls during a month, 
an operator may generate five CDRs from which a monthly bill is generated. 

As described above, prepaid charging means that an amount of service is paid for in 
advance of the service being provided. Real-time prepaid charging also is defined above. 

Another type of prepaid charging is "hot billing", which some MCN operators 
provide to attempt to emulate some of the capabilities of real-time prepaid charging. Hot 
billing is implemented by generating CDRs at periodic intervals throughout a session or 
telephone call. The smaller such an interval is configured, the less amount of time a 
subscriber is able to exceed a threshold amount of service, and the closer hot billing 
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emulates the ability of real-time prepaid charging to prevent a subscriber from exceeding a 
threshold amount of service. Each time a CDR is generated, the CDR may be reported to a 
billing module (e.g., charging gateway 45 of Fig. 5), which typically resides on a network 
node separate from the node on which the metering occurs, and further instructions may be 
5 awaited from the billing module. For example, a PSM may generate a CDR every five 
minutes for a session on an MCN, and report the CDR to a billing module presiding on 
another node of the MCN. The billing module then may determine if the subscriber has 
enough credit or a plan that enabled the subscriber to continue the session. The billing 
module then may send the PSM instructions regarding whether to terminate the session or 
10 continue. 

A problem with hot billing is that a subscriber may be able to use a service beyond 
that for which the subscriber has paid or contracted. For example, if the subscriber has 55 
minutes and 1 second of credit remaining in their account, and CDRs are being generated 
every five minutes, then after the eleventh CDR, the billing module will allow the subscriber 

1 5 to continue a session or telephone call for an additional five minutes, thereby allowing the 
subscriber four minutes and 59 seconds of extra use. 

Further, although the ability to obtain such extra use may be reduced by reducing the 
CDR-generation interval, such reduction results in more CDRs being generated, thereby 
increasing the traffic load of the MCN. 

20 IE 1 014 further may specify different types of prepaid charging. For example, IE 

1014 may specify a typical type of packet-switched pre-paid charging such as CAMEL 
Phase 3 on a GPRS, GMS/GPRS or UMTS network. Alternatively, IE 1014 may specify a 
type of prepaid charging where the SSF module communicates with the SCF module in 
accordance with circuit-switched voice prepaid charging, but the SSF module implements 

25 prepaid charging in accordance with packet-switched prepaid charging. This type of prepaid 
charging may be referred to herein as packet/circuit-switched prepaid charging. For 
example, IE 1014 may specify that the SSF module communicates with the SCF module in 
accordance with CAMEL Phase 2, and that the SSF module implements prepaid charging in 
accordance with CAMEL Phase 3. Further, for such CAMEL Phase 2/Phase 3 -type prepaid 

3 0 charging, IE 1 0 1 4 may specify whether this type of prepaid charging meters the duration of 
the PDP context session or meters a number of information units transmitted during the PDP 
context session. 
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PIM 344A may be configured to implement one or more types of charging for a 
packet-based service, including postpaid charging, flat-rate charging, hot billing, one or 
more types of prepaid charging and other types of charging, 

IE 1015 specifies a calling party number for the PDP context. IE 1015 may map a 

5 telephone number to a PDP context session, and can be useful for packet/circuit-switched 
prepaid charging. For example, for a given subscriber, circuit-switched INS functionality 
149 may include a phone number associated with the subscriber, but may not have the 
capability of associating a PDP context session with the subscriber. Consequently, if the 
SSF module 362 attempts to access the circuit-switched INS functionality 149 using a PDP 

10 context ID, the SCF module 148 will not understand the PDP context ID. 

Associating a calling party number with a PDP context session enables the SSF 
module 362 to specify a telephone number to the SCF module 148 when attempting to 
initiate use of an INS. The SCF module 148 then can recognize the telephone number and 
be able to control implementation of the INS. Thus, by mapping a telephone number to a 

15 PDP context session, the SCF module 148 does not need to be configured (e.g., updated or 
replaced) to recognize a PDP context ID. 

In some cases, the calling party number may be a telephone number already 
associated with a subscriber. For example, if the MCN is a GSM/GPRS network, the calling 
party number may be the telephone number assigned to the subscriber and stored in an MSC 

20 of the GSM network. 

IE 1016 specifies a called party number for the PDP context. As will be described 
below in relation to IE 1 104 of an APN profile 1 101, IE 1 104 may specify a called party 
number that defines a default charging plan for an APN to be used for any PDP context 
session that uses the service defined by the APN. Such a called party number may enable an 

25 SCF module configured to implement prepaid charging for circuit-switched voice services 
to associate a charging plan with a PDP context session. IE 1016 specifies a called party 
number that may be associated with a specific subscriber that overrides the called party 
number associated with the APN specified by IE 1010. The ability to associate a called 
party number with a specific subscriber enables a charging plan to be associated with 

3 0 particular subscriber when the subscriber establishes a PDP context session with a node of a 
PDN. 
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IE 1018 specifies a charging rate modifier for aPDP context. This charging rate 
modifier enables customizations for a particular subscriber of a generic charging plan 
associated with an APN. 

PDP context profile data structure 1000 may include additional information elements 
5 that store values corresponding to the values stored in IEs 1 1 1 6 and 1 1 1 8 of APN profile 
data structure 1 100 described below in relation to Fig. 10. The value of these IEs of data 
structure 1000 may override, be combined with or be overridden by the corresponding 
values stored in IEs 1 1 1 6 and 1 1 1 8 . 

Fig. 10 is a block diagram illustrating an example of an APN profile data structure 
10 1 1 00 for an APN configured for prepaid charging. Data structure 1100 may include one or 
more APN profiles 1101, each profile 1 101 including one or more IEs. Data structure 1 100 
may be any of a variety of types of data structures, including an object, a table, or a plurality 
of records separated by delimiters. Other types of data structures also may be used. 

An APN profile 1 101 may define an access agreement between the MCN of NSS 
15 310 and a PDN (e.g., PDN 6B). Profile 1101 may define access points (e.g., port addresses 
of a PIM) that serve as interfaces between NSS 310 and one or more PDNs, and also may 
define, for an APN, one or more access methods (e.g., open IP, tunneled, encrypted, etc.) 
that may be used by the interfaces. 

One or more of the information elements of an APN profile 1 101 may define values 
20 of service parameters for a service provided to subscribers of the MCN of NSS 3 1 0. Some 
of these values may be defined to be overridable by values of the service parameters 
specified for a specific subscriber as defined in corresponding PDP context profile 1001. 
Other values may be defined so that they cannot be overridden by values specified for a 
subscriber, and other values may be defined to be combined (e.g., aggregated) in some 
25 " fashion with values defined for a subscriber. 

Each entry 1 101 may include an APN IE 1 102, a called party number IE 1 104, a 
tariff switch time IE 1 1 06, a time-to-count conversion ratio IE 1 1 07, a count metering unit 
IE 1 1 08, a time-based reporting IE 1 1 1 0, a count metering downlink/uplink ratio IE 1 1 1 2, a 
port address list IE 1 1 13, a charging-type IE 1 1 15, an APN profile distribution IE 1 1 14 a 
3 0 top-up opportunity IE 1 1 1 6, pop-up/top-up information IE 1 1 1 8 and one or more other IEs. 
IE 1 1 02 specifies an APN, and may be used as a key for an APN profile 1101. 
IE 1 104 specifies a called party number associated with the APN. An SCF module 
148 may not be configured to associate an INS with an APN; however, an SCF module 148 
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may have the ability to associate a telephone number with an INS. For example, circuit- 
switched INS functionality 149 may recognize a telephone number for a subscriber 
associated with an INS. Accordingly, called party number 1 104 may be used to map a 
telephone number to the APN specified in IE 1102. Thus, when SSF module 362 attempts 
5 to initiate an INS with SCF module 148 for a packet-switched service using the APN, SSF 
module 362 may specify the telephone number defined by IE 1 104. Accordingly, the SCF 
module 148 can control implementation of the INS using a telephone number, and the SSF 
module can map this telephone number to the APN specified by IE 1 102. 

IE 1 1 06 specifies a tariff switch time associated with prepaid charging for this APN. 
1 0 A tariff switch time is used for circuit-switched voice prepaid charging to specify a time at 
which a charging rate changes for an APN. For example, a charging plan associated with 
the APN may specify that before 8:00 p.m. a first rate applies, but after 8:00 p.m. a second 
rate applies. 

If the type of prepaid charging specified by IE 1014 is time-based prepaid charging, 
1 5 then IE 1 1 06 may be used to determine when a report is to be transmitted from an SSF 
module to an SCF module so that the SCF module may determine a new time threshold 
based on the prepaid amount and new charging rate. If the type of prepaid charging is 
count-based prepaid charging, the tariff switch times specified by IE 1 106 may be used by 
an SSF module to recalculate a count threshold based upon a prepaid amount and new 
20 charging rate, as will be described below in more detail in relation to Figs. 12A and 12B. 

IE 1 107 may specify a time-to-count conversion ratio to be applied to convert a call 
period to a count and vice versa for the APN specified by IE 1 1 02. For example, IE 1 1 07 
may specify a ratio for converting minutes or seconds to a count corresponding to a number 
of information units, e.g., packets, kilobytes or bytes. Other conversion ratios and units may 
25 be used. 

Count metering unit 1 108 specifies the information unit to be used to meter the 
number of information units exchanged of a PDP context session, for example, byte, 
kilobyte, packet, transaction, or other information unit. 

IE 1 1 10 may specify whether time-based reporting is to be used between an SSF 
30 module and an SCF module for a PDP context session of the APN for which count-based 
prepaid charging has been defined. In other words, although the number of exchanged 
information units may be metered for a PDP context session, as opposed to metering the 
duration of the PDP context session, an SSF module may still report usage to an SCF 
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module at predetermined time intervals, so that the SCF module can receive up-to-date 
usage information. Such up-to-date usage information may be desirable for long PDP 
context sessions with relatively low data traffic. For example, the tariff switch time 
specified by IE 1 106 may be used as an interval at which to report to the SCF module the 
5 amount of time used (where this amount of time has been converted from the number of 
information units exchanged). It may be desirable to use the tariff switch time for the 
reporting interval because the charging rate may change after the tariff switch time has 
elapsed, and the SCF module may be configured to provide updated information to the SSF 
module in accordance with the change of charging rate. 

10 IE 1 1 12 specifies a count metering downlink/uplink ratio to be applied to a count 

threshold. The term "uplink" as used herein refers to a direction of transmission of a packet 
exchanged as part of a PDP context session, where the packet originated from the MT of the 
subscriber for which the PDP context session is being implemented. As used herein, the 
term "downlink" refers to a direction of transmission of a packet exchanged as part of a PDP 

1 5 context session, where the packet is to be terminated at the MT of the subscriber for which 
the PDP context session is implemented. Thus, the count metering downlink/uplink ratio 
specifies the ratio of downlink packets of the PDP context session to uplink packets of the 
PDP context session. The SSF module 362 may be configured to apply this ratio in 
allocating downlink and uplink information units to a downlink count threshold and an 

20 uplink count threshold, respectively, and then separately meter the number of downlink 
information units and the number of uplink infonnation units and compare each number to 
the appropriate count threshold. In response to the downlink count threshold or the uplink 
count threshold being reached, the SSF module may be configured to re-allocate the 
remaining information units between a new downlink count threshold and a new uplink 

25 count threshold. 

IE 1 113 may list one or more port addresses (i.e., IP addresses) that have been 
provisioned to support the APN specified in IE 1 101 . Each port address may correspond to 
a port of a PIM (e.g., PIM 344A) of NSS 310. 

IE 1 1 1 5 specifies a charging-type to be used for the APN specified by IE 1 1 01 . In 

3 0 some cases, the value for the charging type may be overridden by the charging-type 

specified in IE 1014 for a specific subscriber. The value stored in IE 1 1 15 may determine 
whether or not the value itself can be overridden by IE 1014. For example, IE 1 1 1 5 may 
specify an all-prepaid charging type (e.g., real-time prepaid or hot billing) mat defines that 
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any PDP context session for the APN will have prepaid charging applied, regardless of the 
value specified in IE 1014 for a subscriber. IE 1115 also may specify an all-postpaid 
charging type that specifies that any PDP context session established for this APN will have 
postpaid charging applied, regardless of the value specified by IE 1014 for a specific 
5 subscriber. IE 1 1 1 5 also may specify a combined charging type that indicates that the 
charging type will be determined by IE 1014 for each subscriber that uses the service 
represented by the APN defined by IE 1 101. IE 1 1 15 may specify other charging types as 
well. 

IE 1 1 14 specifies an APN profile distribution for the APN profile 1101. For 

10 example, although a particular network element of the NSS 310, for example, SSR 370, may 
be the primary location at which the APN profile 1 101 is stored persistently, the APN 
profile 1101 may be distributed or provisioned to one or more other network elements of 
NSS 310. For example, APN profile 1101 may be provisioned to SSF module 362. Further, 
the complete APN profile data structure 1 100 may be provisioned to one or more other 

1 5 network elements such as SSF module 362. Further, the PDP context profile data structure 
1000, and/or one or more PDP context profiles 1001 thereof, also may be provisioned to one 
or more networked elements of NSS 310, for example, SSF module 362. In a case where a 
PDP context profile 1001 and/or an APN profile 1101 are stored on the SSF module, then, 
in response to a request to establish a PDP context session for the PDP context profile, the 

20 SSF module may not have to exchange communications with the SSR 370 to obtain the PDP 
context profile and/or a corresponding APN profile to establish the PDP context session. 
Storing a PDP context profile and/or an APN profile on the SSF module 362 prior to 
reception of a PDP context request may be referred to herein as "static provisioning." 
Provisioning a PDP context profile or an APN profile to an SSF module in response to a 

25 request to establish a PDP context session may be referred to herein as "dynamic 

provisioning." IE 1 1 14 may specify whether static provisioning or dynamic provisions is to 
be used for the APN of APN profile 1 100. 

IE 1 1 16 stores a value that indicates whether a top-up opportunity is to be provided 
for this service for subscribers. If the value stored in IE 1 1 16 indicates that a top-up 

3 0 opportunity is not to be provided for this service, then when a threshold amount of service is 
reached while the service is being provided, the service may either be terminated or 
continued without the subscriber having an opportunity to add value to an account balance 
for the service. If IE 1 1 16 indicates that a top-up opportunity is to be enabled for a 
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subscriber while the service is being provided, then the subscriber may be enabled an 
opportunity to top-up an account (e.g., postpaid or prepaid) for the service and thereby 
continue the service. A PDP context profile 1001 may have an information element • 
corresponding to IE 1 1 16 that enables a subscriber to define whether a top-up opportunity 
5 will be afforded (e.g., as part of the subscribers' subscription for the service). The value of 
this information element may override, be combined with or be overridden by the value 
defined for IE 1116. 

IE 1 1 18 may store values defining pop-up/top-up information for notifying 
subscribers that a service threshold has been reached and enabling subscribers an 

1 0 opportunity to top-up an account if IE 1 1 1 6 indicates a such opportunity should be afforded. 
IE 1 1 18 may store several values for parameters (or APN Profile 1 100 may include several 
information elements) that control how a pop-up notification will be performed and how a 
top-up opportunity will be enabled for a service. For example, IE 1 1 1 8 may include 
parameters for any of the following: one or more multimedia control protocols to be used for 

1 5 a pop-up notification; one or more multimedia control protocols to be used for a top-up 
opportunity; whether in-band or out-of band session is to be used for a pop-up notification; 
whether in-band or out-of band session is to be used for a top-up opportunity; whether a 
same or different transport path is to be used for a pop-up notification; whether a same or 
different transport path is to be used for a top-up opportunity; the duration for which a top- 

20 op opportunity is enabled; the type of interim processing to be performed during a top-up 
opportunity; interim processing information; and other parameters. The uses of these 
parameters for pop-up notifications and/or enabling top-up opportunities are described 
below in more detail in relation to Act 826 of method 800. 

Returning to Fig. 8, it should be noted that SSR 370 may be included in its entirety 

25 as part of PIM 344A. Further, at least a portion of SSR 370 may be included in SIR 1 50. 
For example, at least a portion of subscriber services information 371, which may include 
one or more PDP context profiles 1001 and/or one or more APN profiles 1101, maybe 
included as part of SIR 150. 

In response to a subscriber attempting to initiate a session for a service, service 

30 support module 36 1 of PIM 344A may download (if not already stored on PIM 344A), from 
the SSR 370, service information 374, which may include the subscriber packet-switched 
INS information 372 along with other subscriber services information 371. Subsequently, in 
response to a triggering event for a service (e.g., a time or volume threshold being reached, a 
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tariff switch time, or a termination of the session), the SSF module 362 may initiate 
communications with the SCF module 148 in accordance with information 374 to request 
and receive instructions and information relating to the triggering event. 

SSF module 362 may be configured to communicate with the SCF module 1 48 to 
5 implement prepaid charging for a packet-switched service provided by a node of a PDN. 
For example, in response to PIM 344A receiving a request to establish a PDP context 
session from a subscriber, the SSF module 362 may send a circuit-switched-INS packet 147 
to SCF module 148 to request INS instructions and information for the session. The circuit- 
switched INS functionality 149 may determine the instructions and information, and the 

1 0 SCF module 148 may send a circuit-switched-INS packet 1 47 including such instructions 
and information to the SSF module 362. 

If the INS is prepaid charging, the packet 147 sent by the SCF module 148 may 
include information for implementing prepaid charging. The SSF module 362 may be 
configured to receive such information and to implement prepaid charging accordingly. 

1 5 Further, the SSF module 362 may be configured to communicate with the SCF module 1 48 
throughout the session in response to one or more other triggering events and/or at 
predetermined intervals. 

SSF module 362, SCF module 148 and SSR 370 may be configured to exchange 
communications and implement an INS as described below in relation to Figs. 1 1, 12A and 

20 12B, including exchanging information described in relation to Figs. 1 3-16. 

hi an embodiment, NSS 310 includes a server-based application that includes the 
service intelligence and logic to enable network operators to develop, deploy, manage, and 
provision INSs while containing operational costs. Such server-based application, and 
portions thereof, may reside on one or more of the modules (e.g., 362, 148, 150 and 370) of 

25 NSS 310. In an embodiment, such server-based application is the Senteon Service Core 

available from WaterCove Networks, Inc. One or more nodes of the MCN illustrated in Fig. 
8, including one or more MTs such as 18A, may be configured with a client side of such 
server application. 

NSS 310, and components thereof such as registers 150 and 370 and modules 136A 
30 and 344A, may be implemented using software (e.g., C, C++, Java, or a combination 

thereof), hardware (e.g., one or more application-specific integrated circuits), firmware (e.g., 
electrically-programmed memory) or any combination thereof. One or more of the 
components of NSN 310 may reside on a single machine (e.g., a node of NSN 310), or each 
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component may reside on a different machine. Further, each component may be distributed 
across multiple machines, and one or more of the machines may be interconnected. 

Further, on each of the one or more machines that include one or more components 
of NSN 310, each of the components may reside in one or more locations on the machine. 
5 For example, different portions of the components 136A, 150, 344A and 370 may reside in 
different areas of memory (e.g., RAM, ROM, disk, etc.) on the machine. Each of such one 
or more machines may include, among other components, a plurality of known components 
such as one or more processors, a memory system, a disk storage system, one or more 
network interfaces, and one or more busses or other internal communication links 

10 interconnecting the various components. 

In an embodiment, NSS 310 may be implemented in accordance with the Mobile 
Data Service System and/or the FlowCore System Architecture developed by Watercove 
Networks, Inc of Chelmsford, Massachusetts, as described in more detail at 
http://www.watercove.com. The Mobile Data Service System and Flowcore are described 

1 5 in more detail in Purpose-Built Architecure Required for Mass-Market Deployment of 

Personalized Data Services and Exploiting the Opportunities for Personalized Mobile Data 
Services, whitepapers available from WaterCove Networks, Inc. of Chelmsford, 
Massachusetts at: http://www.watercove.com/pdf/Purpose.pdf and 

http://www.watercove.com/pdf/Opportunities.pdf , respectively, the entire contents of both 
20 of which are hereby incorporated by reference. 

NSS 3 10 is an illustrative embodiment of an NSS for implementing a packet- 
switched INS and Pop-up/Top-up for packet-switched services on an MCN. Such an 
illustrative embodiment is not meant to limit the scope of the invention and is provided for 
illustrative purposes, as any of a variety of other NSSs for implementing INSs and Top- 
25 up/Pop for packet-switched services on an MCN, for example, variations of NSS 310, may 
fall within the scope of the invention. 

?.. Im plementing Prepaid Charging and Pqp-Up/Top-Up for Packet-Switched Services 
Fig. 1 1 is a flowchart illustrating an example of a method 700 for implementing an 
INS for packet-switched services on a module of an MCN. Such a module may be a PIM 
30 such as PIM 344A or a PSM. 

In Act 702, the execution of an INS for a packet-switched service is initiated. For 
example, a request may be received to create aPDP context session for a packet-switched 
service between a subscriber of the MCN and a node of a PDN. 
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In response to receiving the request, a SSR, for example, SSR 370, may be accessed 
to determine if the subscriber subscribes to one or more INSs. For example, SSF module 
362 may receive a session packet 160, and, in response, service support module 361 may 
access SSR 370, which may access subscriber packet-switched-INS information 372 to 
5 determine INSs, if any, to which a subscriber is subscribed. The subscriber packet- 
switched-INS information 372 also may indicate the identity and location of an SCF module 
to exchange communication with to implement an INS. The SSR 370 may specify this 
information in service information 374 sent to the SSF module 362. 

If the subscriber is subscribed to an INS, an initiating packet may be sent to an SCF 
1 0 module corresponding to the INS to initiate the INS for the requested PDP context session. 

Next, in Act 704, information for the INS may be received from the SCF module. 
In a following Act 706, the INS may be implemented using the received information. 
Further, additional packets may be exchanged between the PIM and SCF module throughout 
the implementation of the INS, for example, in response to a triggering event. Optionally, 
1 5 these packets may be exchanged in accordance with a protocol for implementing the INS 
with circuit-switched voice parameters, and the PIM may be configured to convert the 
circuit-based parameters to packet-based parameters and vice versa. 

In a following act 708, the INS may be terminated. For example, the INS may be 
terminated in response to an action by the subscriber or another party to the session or may 
20 be terminated in accordance with the INS. 

Method 700 is an illustrative embodiment of a method of implementing an INS for 
packet-switched services on a PIM of an MCN. Such an illustrative embodiment is not 
meant to limit the scope of the invention and is provided for illustrative purposes, as any of 
a variety of other methods of implementing an INS for packet-switched services on a PIM of 
25 an MCN, for example, variations of method 700, may fall within the scope of the invention. 
Figs. 12A-12B are a flow chart illustrating an example of a method 800 of 
implementing prepaid charging and Top-up/Pop-up for packet-switched services on module 
of an MCN. Such module may be a PIM such as PIM 344A or a PSM such as PSM 136A. 
Although method 800 is described below primarily in relation to implementing prepaid 
3 0 charging, other INSs may be implemented using such a method or a variation thereof. 

In Act 802, a request to create a PDP context session for a packet-switched service 
between a subscriber and a node of a PDN may be received. For example, referring to Fig. 
8, a subscriber 17A using an MT 18A may transmit a PDP context request to PSM 136A, 
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which forwards the request to PIM 344A. The PDP context request may include PDP 
context access information 900 illustrated in Fig. 13. 

Such information 900 may include one or more information elements (IEs) including 
subscriber ID IE 902, APN IE 904 and PDP Type IE 906. The subscriber ID IE 902 may 
5 specify the IMSI or another unique identifier of the subscriber that originated the request. 
APN IE 904 may specify the APN for the requested PDP context session. Such APN may 
be a label in accordance with known DNS naming conventions. The PDP Type IE 906 may 
specify the type of packet data protocol for the requested PDP context session, for example, 
IPorPPP. 

10 The combination of subscriber ID IE 902 and APN IE 904 may be used to index the 

appropriate PDP Context Profile 1001 from PDP context profile data structure 1000, 
described above in relation to Fig. 9. 

In Act 804, it may be determined whether a subscriber subscribes to prepaid 
charging for the packet-switched service for which a PDP context session is requested. For 

1 5 example, service support module 361 may send a packet to SSR 370 that includes at least 
IEs 902 and 904 of PDP context access information 900 to determine whether the subscriber 
subscribes to prepaid charging for the APN specified in the PDP context request. The SSR 

370 may access subscriber service information 371 to determine whether the information 

371 includes an entry (e.g., a PDP Context Profile 1001) for the specified subscriber and 
20 APN. If the information 371 does not include an entry for the specified APN, the SSR 370 

may send service information 374 to the service support module 361 indicating that it does 
not include any information pertaining to prepaid charging. Further, information 374 may 
indicate that the subscriber is not registered for the requested packet-switched service at all. 
If the subscriber service information 371 does include an entry for the specified APN 

25 for the subscriber (e.g., a PDP context profile 1001), the service information 374 may 

include mformation pertaining to prepaid charging. For example, service information 374 
may include one or more (e.g., all) of the IEs of a PDP context profile 1001 corresponding 
to the subscriber ID and APN specified in PDP context access information 900 transmitted 
from SSF module 362 to SSR 370. Further, the INS information 374 also may include any 

30 of the IEs included in an APN profile 1 101 corresponding to the APN specified in 
information 900. 

As discussed above in relation to IE 1 1 14, an APN may be defined such that the 
APN is dynamically distributed to one or more elements, for example PIM 344 A, of NSS 
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310. Accordingly, service support module 361 may perform Act 804 without accessing SSR 
370 if the specified PDP context profile and/or APN profile have been dynamically 
distributed to service support module 361 before the request is received in Act 802. 

In Act 804, if it is determined that the subscriber does not subscribe to prepaid 
5 charging for the packet-switched service, then prepaid charging may not be implemented for 
the packet-switched service. 

In Act 804, if it is determined that the subscriber subscribes to prepaid charging for 
the packet-switched service, then, in Act 806, an initializing packet may be sent to an 
appropriate SCF module (e.g., SCF module 148) to initiate prepaid charging for the PDP 

10 context session. 

For example, SSF module 362 may send initializing packet 1200, illustrated in Fig. 
14, to SCF module 148. Initializing packet 1200 may include any of the following IEs: INS 
ID IE 1202; called party number IE 1204; calling party number IE 1206; subscriber ID IE 
1208; and one or more other IEs. 

15 IE 1 202 specifies an ID for a set of one or more INSs, which may include prepaid 

charging, for which the SSF module is requesting implementation. The SCF module may be 
configured to implement a plurality of INSs, and IE 1202 enables the SCF module to select 
one or more of the plurality of INSs to implement for the SSF module. 

IE 1204 specifies a called party number to used by the SCF module to access the 

20 INS subscription information specific to the subscriber for the INS. As discussed above in 
relation to IEs 1 0 1 6 and 1 1 04, the called party number may specify a telephone number for 
the subscriber which is mapped to an APN corresponding to the PDP context session. 

IE 1206 specifies a calling party number that specifies the subscriber to the SCF 
module 148. As described above in relation to IE 1 0 1 5 of a PDP context profile 1 00 1 , if an 

25 SCF module such as SCF module 148 is not capable of recognizing a PDP context 

identifier, then the calling party number may specify a telephone number associated with the 
subscriber initiating implementation of the INS. IE 1015 maps this telephone number to a 
PDP context profile 1 00 1 corresponding to a subscriber. If the NSS 3 1 0 is an NSS on which 
both packet-switched services and circuit-switched voice services can be implemented (e.g., 

30 a GSM/GPRS network), the telephone number specified by the calling party number 1206 
may be a telephone number already assigned to the subscriber for circuit-switched voice 
services. 

IE 1208 specifies an ID for a subscriber, for example, an IMS! 
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Returning to method 800, in Act 808, prepaid charging information may be received 
from the SCF module. 

Fig. 1 5 is a block diagram illustrating an example of prepaid charging information 
1300 that may be transmitted from an SCF module to an SSF module as part of 
5 implementing an INS for a PDP context session. The prepaid charging information 1300 
may include one or more of the following IEs: call period duration IE 1302; release IE 1304; 
notify subscriber IE 1306; party to charge IE 1308; tariff switch interval IE 1310; top-up 
opportunity IE 1 3 12; pop-up/top-up information IE 1 3 14; and one or more other IEs. 
IE 1302 may specify a call period duration for the PDP context session in 

1 0 accordance with the amount of service prepaid for by the subscriber. IE 1 3 04 is a flag that 
may specify whether to terminate (i.e., release) the PDP context session if the call period 
(i.e., the number of information units or elapsed time converted from the call period) has 
expired. The value stored in IE 1302 may be related or depend on one or more values stored 
in IEs 13 12 and 13 14, as will be described below in more detail. 

15 IE 1 306 specifies whether to notify the subscriber that the threshold has been 

reached before terminating the PDP context session. IE 1306 may be used if IE 1304 
indicates to terminate the PDP context session in the event that the call period has expired. 
If IE 1306 indicates to notify the subscriber, then the service support module 361 may be 
configured to notify the MT of the subscriber using video content, audio content, data 

20 content or a combination thereof, and the MT may be operative to play a sound, play an 
audio or video message, display a visual message or in some other fashion notify the 
subscriber that the threshold has been reached. Further, the SSF module and the MT may be 
operative to allow a subscriber a certain amount of time during which to top-up before 
terminating the PDP context session, as described in more detail below. 

25 The SSF module may send such notification at a predetermined amount of time 

before the actual PDP context session is terminated, for example, 30 seconds before a PDP 
context session is terminated. Thus, the SSF module may be configured to recognize when 
the number of information units or amount of time remaining for the PDP context session is 
equivalent to an amount of time (e.g., 30 seconds) before the call period would expire, and 

30 to notify the subscriber of the imminent termination in response to such recognition. The 
value stored in IE 1306 may be related or depend on one or more values stored in IEs 13 12 
and 1314, as will be described below in more detail. 
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IE 1308 may specify a party to charge for the PDP context session. For example, IE 
1308 may specify the subscriber's IMSI or another identifier of the subscriber. Further, IE 
1308 may specify another party associated with the subscriber for which to charge. The 
value specified by IE 1308 should match the value specified by IE 1406 discussed in more 
5 detail below in relation to Fig. 1 6. 

IEs 1 3 1 0, 1 3 1 2 and 1 3 1 4 may contain information defined in IEs 1 1 06, 1 1 6 and 
1118, respectively, of an APN profile 1 100 for the service being provided, and may be 
combined with or overridden by information defined in corresponding IEs of a PDP context 
profile 1000 for the subscriber and service. 
10 In Act 8 1 0, it may be determined whether the subscriber has a sufficient prepaid 

balance for the requested packet-switched service. For example, the prepaid charging 
information received in Act 808 may indicate that the subscriber does not have a required 
minimum balance in the subscriber's prepaid account for the service associated with the 
PDP context session. 

1 5 Returning to method 800, in Act 8 10, if it is determined that the PDP context session 

is not to be terminated, then in Act 812 the call period may be converted to a count threshold 
or elapsed time threshold for the PDP context session. The SSF module may use a variety 
of techniques for converting the call period. If the charging type for the PDP context 
session, specified by IE 1014, is time-based (e.g., time-based prepaid charging), the SSF 

20 module may merely use the call period as the elapsed time threshold or may apply a 
function, possibly as simple as multiplying by a factor, to convert the call period to an 
elapsed time threshold. 

If the charging type for the PDP context session specified by IE 1014 is count-based 
prepaid charging, then Act 812 may include applying the time-to-count conversion ratio 

25 specified by IE 1 107 of the APN profile 1 101 corresponding to the PDP context session. 
For example, the time-to-count conversion ratio may specify that 1 second of call period 
translates to 56 kilobytes. Accordingly, if a subscriber has prepaid for 10 minutes of the 
PDP context session, then the count threshold count for the PDP context session will be 33.6 
megabytes. 

30 If the specified charging type for the PDP context session is count-based prepaid 

charging, then Act 812 also may include allocating the count threshold between an uplink 
count threshold and a downlink count threshold, for example, in accordance with IE 1 1 12 of 
the APN profile 1101 corresponding to the PDP context session. 
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For example, referring to Fig. 8, for a PDP context session between a subscriber 17A 
using an MT 1 8A and PDN node 66, after receiving a count threshold from SSF module 
662, PIM 344A may meter the number of information units exchanged by incrementing the 
accumulative number of information units received as part of forwarding uplink session 
5 packets 1 60 and compare the accumulative number to the uplink threshold count, and may 
separately meter the number of hxformation units received as part of forwarding downlink 
session packets in the same maimer. If either the uplink or the downlink threshold count is 
reached, the PIM 344A may report both uplink and downlink usage to the SSF module 362, 
and if the combined usage is still smaller than the original total count threshold converted 

10 from the call period received from the SCF module 148, the SSF module may be configured 
to re-allocate the remaining information units between a new uplink threshold count and a 
new downlink threshold count. 

In Act 814, die duration of die PDP context session and/or a number of information 
units exchanged between the subscriber and the PDN node during the PDP context session 

15 may be metered. Act 8 14 may include applying the count metering unit specified by IE 
1 108 to determine what unit to use for metering. Thus, the SSF module may meter the 
number of information units exchanged (e.g., bytes, kilobytes, packets or transactions) 
during a PDP context session. 

It should be appreciated that although metering a number of information units 

20 exchanged in a duration of a session are described throughout here, an event that takes place 
during a service may have a value associated with it that correlates to an amount of service 
that must be metered as part of the session metering process. For example, a service 
provider may charge a flat fee for a subscriber to download a particular file. Although not 
described above, an APN profile 1 101 or a PDP context profile 1001 may have one or more 

25 information elements that define values corresponding to a particular service event (e.g., 
downloading a particular file). These information elements may be used during the 
metering process, for example, by a service support module such as module 361, to meter 
the amount of service associated with the event when the event occurs during the providing 
of the service. 

3 0 Although not illustrated in method 800, a prepaid charging report (e.g. prepaid 

charging report 1400) may be generated by a session support module (e.g., session support 
module 363) at predefined periods (e.g., based on EEs 1302 and/or 1310 described above) or 
in response to a triggering event. Such report may transmitted to a service support module 
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(e.g., service support module 361) and may be transmitted by an SSF module (e.g. SSF 
module 362) to an SCF module (e.g., SCF module 148) The metered number of information 
units exchanged or time elapsed may be converted to a call period. For example, the inverse 
function of the function applied in Act 812 may be applied to produce the call period. Such 
5 a conversion may be made by applying the reverse ratio of the ratio specified by IE 1 1 07 of 
the APN profile 1101. 

Fig. 1 6 is a block diagram illustrating an example of a prepaid charging report 1 400. 
Prepaid charging report 1400 may include one or more of the following IEs: time elapsed if 
no tariff switch IE 1402; time elapsed if tariff switch IE 1404; party to charge IE 1406; 

10 session active IE 1408; and one or more other IEs. 

Depending on die type of prepaid charging and whether a tariff switch has occurred, 
either IE 1402 or 1404 may specify how much time has elapsed since the last prepaid 
charging report, or since the beginning of the PDP context session, or since the last tariff 
switch. If die type of prepaid charging for the PDP context session is time-based prepaid 

1 5 charging and a tariff switch has occurred since the last prepaid charging report 1 400 was 
sent (which may be the reason why the prepaid charging report is being sent), then IE 1404 
may specify the elapsed time since the last tariff switch. 

If the type of prepaid charging for the PDP context session is time-based prepaid 
charging, but no tariff switch has occurred since the last prepaid charging report was 

20 transmitted, or if die type of prepaid charging is count-based prepaid charging, then IE 1402 
will specify the time elapsed since the last prepaid charging report, or since the beginning of 
the PDP context session, or since the last tariff switch. The time elapsed may be the result 
of a conversion from a time or count threshold as described above. 

The SSF module may be configured to send a prepaid charging report 1400 (e.g., to 

25 a service support module and/or an SCF module) for other reasons besides the reaching of a 
threshold or the occurrence of a tariff switch. For example, the session support module 363 
and/or the SSF module may be configured to generate a prepaid charging report 1400 at 
periodic intervals during the metering of the number of information units exchanged for a 
PDP context session. 

30 For example, the session support module and/or SSF module may be configured to 

generate a prepaid charging report 1400 at periodic intervals equal to the interval of a tariff 
switch if: a) the type of charging for the PDP context session as specified by IE 1014 is 
count-based prepaid charging; b) IE 1 106 for the APN of the PDP context session specifies 
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a tariff switch time for the APN; and c) IE 1 1 10 for the APN specifies that time-based 
reporting is to be utilized. Accordingly, at the occurrence of a tariff switch during the PDP 
context session, the session support module and/or the SSF module will report the amount of 
time elapsed since a last prepaid charging report was transmitted using IE 1402 of a prepaid 
5 charging report 1400. 

IE 1406 specifies a party to charge for the PDP context session. As described above 
IE 1406 should match IE 1308 of prepaid charging information 1300 corresponding to the 
PDP context session. 

IE 1408 specifies whether the PDP context session is still active or the report 1400 
1 0 was generated and ttansmitted as a result of the PDP context being terminated. 

Returning to method 800, in Act 816, it may be determined whether an instruction to 
terminate the PDP context session has been received. For example, the SSF module may 
receive an instruction to terminate the PDP context session from the MT of the subscriber. 

In Act 816, if it is determined that an instruction to terminate the PDP context 
1 5 session has been received, then the method proceeds to Act 8 1 9, described below. Although 
Act 816 illustrates determining whether such instruction has been received at a particular 
point during performance of method 800, it should be understood that at any point during 
the method 800, such an instruction may be received and the method may proceed to Act 
819. 

20 If it is determined in Act 8 1 6 that an instruction to terminate the PDP context session 

has not been received, then in Act 81 8, it may be determined whether a threshold has been 
reached, or, alternatively, whether a threshold is close to being reached. For example, it 
may be determined whether a time threshold for the duration of the PDP context session has 
been reached and/or a count threshold (i.e., a total of a combination of an uplink count 

25 threshold and a downlink count threshold) has been reached. Although Act 8 1 8 is illustrated 
as occurring at a particular point during performance of method 800, it should be understood 
that the threshold being reached is an event that may occur at any point during performance 
of method 800. 

If it is determined that a threshold has not been reached, then method 800 may return 
30 to Act 8 1 4. If it is determined in Act 8 1 8 that a threshold has been reached (or is close to 
being reached) then processing may continue to Act 819. 

In Act 819 the subscriber may be notified that the prepaid balance is insufficient for 
the service. The manner in which such notification is performed may be determined based 
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on several factors, including information received in IE 1314. It should be noted that such 
notification may be performed regardless of whether an opportunity to top-up is 
afforded. 

Fig. 17 is a block diagram illustrating some aspects of providing pop-up notifications 
5 and top-up opportunities for services provided on a communications network. Such network 
may include a user terminal 3 1 8, which may be an MT, a Wireless Access Sub-network 
(WAS) 12 and anNSS 310. NSS 310 may include a PIM 344A and a storage medium 384 
that may include a cache 384. NSS 3 10 also may include other network elements, for 
example, any of the network elements described above in relation to Figs. 3-8. 

1 0 A subscriber may be notified of a threshold amount of service being reached using 

the same session as is being used to provide the service (in-band) or using a different session 
(out-of-band). For example, PDN node 66 may be providing a service to user 3 1 7 of user 
device 318 along transport path 382. Accordingly, subscriber 317 may be notified of a 
threshold amount of service being reached as part of the same session along the transport 

15 path 382. 

An out-of-band notification may be sent along a same or different transport path than 
the path on which service packets are exchanged with the user terminal to provide the 
service. For example, for a session along transport path 382, an out-of-band notification may 
be sent along transport path 382 as part of a different session or along a different transport 

20 path 3 80. An out-of-band notification may result from an application sending the 

notification other than the application providing the service. For example, PDN node 66 
may be exchanging session packets 162 with PIM 344A to provide a service along transport 
path 380, but PDN node 67 may include an application that exchanges session packets 163 
with PIM 344A to send the notification along a different transport path 382. 

25 In an embodiment, a subscriber may be notified of a threshold being reached using a 

Short Message Service (SMS) by sending an SMS message to the subscriber. 

An example of an in-band technique may be a dialogue box which can be presented 
in a windowing environment. This dialogue box may "pop-up" on the subscriber's screen of 
the user terminal (e.g., user terminal 318), and alert the subscriber 317 that the threshold has 

30 been reached. The pop-up could also prompt the subscriber for input from a keyboard, 
stylus, mouse or other input device to "top-up" or add value to the prepaid account. 

In a following Act 820, it may be determined whether to terminate the PDP context 
session because of the insufficient balance. Such determination may be made in accordance 
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with IE 1304 and 13 12 (and possibly 1314) described above in relation to Fig. 1 5. For 
example, if IE 1312 specifies that no Top-up/Pop-Up opportunity is to be afforded the 
subscriber, and IE 1304 indicates to terminate the PDP context session, then the PDP 
context session may be terminated. Alternatively, even though IE 13 12 may specify that no 
5 Top-up/Pop-Up opportunity is to be afforded the subscriber, IE 1 304 may indicate to 
continue the PDP context session anyway, and then the PDP context session may be 
continued, and perhaps postpaid charging applied. ' 

If it is determined in Act 820 to terminate the PDP context session, then processing 
continues to Act 830. 

1 0 In Act 830, it may be determined whether any additional information units have been 

exchanged or time has elapsed since the last report was transmitted to the SCF module. As 
will be described in more detail below, at periodic intervals during the duration of the PDP 
context session and/or in response to an event, an SSF module (e.g., SSF module 362) may 
report usage information (e.g., information units exchanged or time elapsed) to the SCF 

1 5 module. During the interim in which the SSF module is waiting for a response from the 
SCF module, time has elapsed and more information units may have been exchanged or 
more time may have elapsed. The time elapsed and/or number of information units 
exchanged may be metered by metering module 365. Accordingly, the metering module 
365 may meter the amount of information units exchanged or the time elapsed since the last 

20 report was transmitted. The metering module 365 may periodically record the time elapsed 
or information units exchanged to the SSF module 362. The frequency and timing of such 
reports may be synchronized with the usage reported by the SSF module 362 to the SCF 
module 148, or may be different. 

If the service support module 361 already established the PDP context session and/or 

25 the session support module 363 already began exchanging packets for the session, then, in 
Act 83 1 , the conversion module 3 66 may convert the additional number of information units 
exchanged or time elapsed to an excess call period. Converting from information units or 
time elapsed to a call period is described below in more detail in relation to Act 826. 

In a following Act 832, as part of sending a prepaid charging report (e.g., prepaid 

30 charging report 1400), the session support module 363 and/or the SSF module 362 may 

report that an instruction to terminate has been received or that a threshold has been reached, 
and report the excess call period to the SCF module. 
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If in Act 830 it is determined that no additional information units were exchanged or 
time elapsed, for example, because the service support module 361 did not yet establish that 
PDP context session, then method 800 ends. 

Returning to Act 820, if it is determined in Act 820 that the PDP context session is 
not to be terminated, then in Act 822 the subscriber may be enabled a top-up opportunity to 
add value to the prepaid account for the service. The manner in which such opportunity 
may be enabled may depend on several factors, including information received in IE 1314. 

Similarly, as described above with respect to Fig. 17 for pop-up notifications, a 
subscriber of a communications network may be enabled to top-up a service account while 
the service is being provided using the same session as is being used to provide the service 
(in-band) or using a different session (out-of-band). Further, top-up packets may be sent 
along a same or different transport path than the path on which service packets are 
exchanged with the user terminal to provide the service. 

To notify the client that a threshold for a service has been reached and/or to enable 
the client to top-up, either in-band or out-of-band sessions may be used based on any of a 
number of factors, including characteristics of the session implementing the service (e.g., 
the multimedia control protocol being used and the type and format of media content being 
exchange as part of the session), the capabilities of the user terminal (e.g., 
whether the user terminal can play audio content, play video content or process data content, 
or any combination thereof), the capabilities of the application and application server 
providing the service, or any combination thereof. 

A session for providing a multimedia service may be implemented using a 
multimedia control protocol capable of controlling (e.g., initiating, maintaining and 
terminating) a session that includes the exchange of multimedia content, including audio, 
video, data or any combination thereof. For example, such protocol may be the Session 
Initiation Protocol (SIP). The SIP protocol is defined in RFC 2543, SIP: Session Initiation 
Protocol by Internet Engineering Task Force (IETF) as of October 26, 1999. Other such 
multimedia control protocols may be used, including Telephony Application Programming 
Interface (TAPI), Telephony Server Application Programming Interface (TSAPI), H.323, 
Media Gateway Control Protocol (MGCP), MEGACO, Open Services Architecture (OSA), 
PARLAY, Java Advanced Intelligent Network (JAIN), and ad hoc IP-based protocols. In an 
aspect of this embodiment, the subscriber is notified in-band that a threshold amount of 
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service has been reached and/or enabled to top-up in-band using a multimedia control 
protocol. 

In a next Act 824, interim operations may be performed while the subscriber is 
provided the opportunity to add value to the prepaid account. Several different types of 

5 interim operations may be performed. The interim operations, and the manner in which the 
interim operations are performed may depend on several factors, including information 
received in IE 1314. 

A subscriber may be enabled to top-up an account for a service using any of a 
variety of techniques. For example, a service may be suspended during the top-up process. 

1 0 Such suspension may allow a top-up to occur without affecting the service application or 
applications that are transmitting data at the point in time that a threshold amount of service 
is reached. This capability is useful in any number of circumstances, for example, in multi- 
player gaming contexts where a player may be interested in continuing a current session 
without having to restart the session as a result of a top-up being performed, or if a large file 

1 5 is being transferred to a subscriber as part of an application when a threshold is reached. 

While the service is suspended, service content transmitted from the service provider 
to the subscriber on the subscriber's terminal may be buffered (e.g., cached) in a buffer (e.g., 
cache 386) while the subscriber is provided the opportunity to top-up the account. After the 
subscriber tops-up or after the opportunity to top-up has elapsed, the buffered content then 

20 may be transmitted to the user terminal. While such buffered content is being transmitted 
from the buffer to the user terminal, any additional service content transmitted from the 
service provider to the end station may continue to be cached until the buffer is empty, at 
which point any additional transmitted service content may be transmitted (i.e., forwarded) 
directly to the user terminal without being buffered. In this example, the application 

25 providing the service may remain unaware that the subscriber has reached a threshold for 
this service, and thus continually transmit content while the subscriber is enabled the 
opportunity to top-up. Such technique is useful in a situation where it is not desirable to 
terminate a session when large volumes of content (e.g., a large data, video or multimedia 
file) are being downloaded such that the large content is lost and would have to be re- 

30 transmitted after another session is established (perhaps after paying a bill or adding more 
value to a prepaid account). 

In another example of this embodiment, while the subscriber is being enabled to top- 
up a prepaid account for a service, a different billing method, for example, postpaid 
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charging, is applied for the service until the subscriber tops-up or until the opportunity to 
top-up has elapsed. 

Fig. 18 is a flow chart 1800 illustrating an example of a method of suspending a 
session while a top-up opportunity is enabled. 
5 In Act 1 802, the session may be suspended. For example PIM 344A may serve as a 

proxy for a user terminal such that all communications from the server application to the 
terminal are not forwarded by the PIM as they would be if the session was active. The PIM 
also may serve as a proxy for the server by capturing all communications transmitted from 
the user terminal to the application server. 

10 In Act 1 804, the PIM may maintain values for session states from the time at which 

the threshold was reached. In Act 1806, the PIM 344A may capture all session content 
transmitted from a server (e.g., from PDN node 66) and buffer such session content in cache 
386 of storage medium 384. 

Such buffering of session content may continue until it is determined in Act 808 that 

1 5 the account has been topped-up or alternatively that the top-up opportunity has lapsed. If 
die top-up opportunity has lapsed, then the session may be terminated. 

If the account has been topped-up, then in Act 18 10 the content of the buffer may be 
transmitted to user terminal 318. While the buffered content is being transmitted in Act 8 1 0, 
any new content being received from the application server will also be buffered in cache 

20 386 until the buffer is empty. When the buffer is empty, then, in Act 1812, the session may 
be restored using the session values maintained from the time at which the threshold was 
reached, and the buffered session content may be forwarded to the user terminal in Act 
1814. 

Method 1800 may include additional acts. Further, the order of the acts performed 
25 as part of method 1 800 is not limited to the order illustrated in Fig. 1 8 as the acts may be 
performed in odier orders, and one or more of the acts of method 1800 may be performed in 
series or in parallel to one or more other acts. For example, Acts 1802 and 1804 may be 
performed in parallel. 

Method 1800 is an illustrative embodiment of a method of suspending a session 
30 while a top-up opportunity is enabled. Such an illustrative embodiment is not meant to limit 
the scope of the invention and is provided for illustrative purposes, as any of a variety of 
other methods for suspending a session while a top-up opportunity is enabled, for example, 
variations of method 1800, may fall within the scope of the invention. 
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The ability to suspend a session, for example, as described above with respect to Fig. 
18, may be programmed through the API for a service (e.g., using information elements of 
an APN profile 1 101) and on a session-by-session basis (e.g., using information elements of 
aPDP context profile 1001). 
5 In another interim operation, as a subscriber is being enabled an opportunity to top- 

up, another service (e.g., a "free" Internet service) is provided for the subscriber. 

In another embodiment of the invention, when a threshold amount for a prepaid 
service is reached, a different billing method, for example, postpaid charging, is applied for 
the service. As used herein, a "prepaid service" is a service for which a subscriber has 
1 0 subscribed for prepaid charging, or a service for which prepaid charging is applied. 

Returning to method 800, in Act 826, it may be determined whether the subscriber 
has added value to the prepaid balance for the service. If the subscriber has added value, 
then processing continues to Act 808, described above. 

If it is determined that the subscriber has not added value to the prepaid account, 
15 then, in Act 828, it is determined whether the opportunity to add value has elapsed. The 
duration for which the subscriber has an opportunity to top-up the prepaid account may be 
based on the pop-up/top-up information defined by IE 1 3 14. 

If it is determined that the opportunity to add value has elapsed, then processing may 
proceed to Act 830 described above. If it is determined that the opportunity to top-up has 
20 not elapsed, then processing may proceed to Act 824. 

It should be noted that although Acts 822, 824, 826 and 828 are illustrated as 
occurring sequentially, any combination of these Acts may occur concurrently, as the 
processing described by these Acts may be event-based processing which may occur in 
response to events. For example, a pop-up message may be played or displayed on a display 
25 screen of the MT of the subscriber offering the subscriber an opportunity to add value to the 
prepaid account while interim operations are being performed. Any time during which this 
opportunity is being offered to the subscriber and the interim operations are being 
performed a notification may be received that the subscriber has added value to the prepaid 
balance or the opportunity to add value has elapsed. 
30 Returning to act 810, if it is determined in Act 810 that the subscriber does not have 

a sufficient prepaid balance for the requested service, then processing may continue to Act 
819, described above 
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Method 800 may include additional acts. Further, the order of the acts performed as 
part of method 800 is not limited to the order illustrated in Figs. 12A-12B as the acts may be 
performed in other orders, and one or more of the acts of method 800 may be performed in 
series or in parallel to one or more other acts. For example, as described above, Acts 816 
5 and 818 may be performed at any point during performance of method 800. 

Method 800 is an illustrative embodiment of a method of implementing prepaid 
charging for packet-switched services on a module of an MCN. Such an illustrative 
embodiment is not meant to limit the scope of the invention and is provided for illustrative 
purposes, as any of a variety of other methods of implementing an INS for packet-switched 

10 services on a PIM of an MCN, for example, variations of method 800, may fall within the 
scope of the invention. 

Methods 700 and 800, described above in relation to Figs. 11, 12A and 12B, other 
methods described above, and acts thereof, respectively, and various embodiments and 
variations of these methods and acts, individually or in combination may be implemented as 

15 a computer program product tangibly embodied as computer-readable signals on a 

computer-readable medium, for example, a non-volatile recording medium, an integrated 
circuit memory element, or a combination thereof. Such a computer program product may 
comprise computer-readable signals tangibly embodied on the computer-readable medium, 
where such signals define instructions, for example, as part of one or more programs, that, 

20 as a result of being executed by a computer, instruct the computer to perform one or more of 
the methods or acts described herein, and/or various embodiments, variations and 
combinations thereof. Such instructions may be written in any of a plurality of 
programming languages, for example, Java, Visual Basic, C, or C++, or any of a variety of 
combinations thereof. The computer-readable medium on which such instructions are 

25 stored may reside on one or more of the network elements of NSS 3 1 0 described above, and 
may be distributed across one or more of such network elements. 

Having now described some illustrative embodiments of the invention claimed 
below, it should be apparent to those skilled in the art that the foregoing is illustrative and 
not limiting, having been presented by way of example only. Numerous modification and 

3 0 other illustrative embodiments are within the scope of one of ordinary skill in the art and are 
contemplated as falling within the scope of the claims set forth below. In particular, 
although many of the examples presented herein involve specific combinations of method 
acts or system elements, it should be understood that those acts and those elements may be 



WO 2002/101624 PCT/US2002/017492 
-60- 

combined in other ways to accomplish the same objectives. Acts, elements and features 
discussed only in connection with one embodiment of a system or method are not intended 
to be excluded from a similar role in other embodiments. Further, for the one or more 
means-plus-function limitations recited in the following claims, the means are not intended 
5 to be limited to the means disclosed herein for performing the recited function, but are 
intended to cover in scope any equivalent means, known now or later developed, for 
performing the recited function. 

In the claims, all transitional phrases such as "comprising", "including", "carrying", 
"having", "containing", "involving", and the like are to be understood to be open-ended, i.e., 
1 0 to mean including but not limited to. Only the transitional phrases "consisting of and 

"consisting essentially of, respectively, shall be closed or semi-closed transitional phrases 
as set forth in the United States Patent Office Manual of Patent Examining Procedures, 
section 21 11.03. 

What is claims is: 
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1 . A method of providing a session between a user terminal used by a subscriber and a 
server of a communications network providing a service to the subscriber, wherein the 
session involves the exchange of at least one of data content and video content, and the 
subscriber has a account balance for the service, the method comprising acts of: 

(A) maintaining a threshold for the service during the session, the threshold 
corresponding to the account balance; 

(B) metering an amount of the service used during the session; 

(C) determining that the threshold has been reached; 

(D) notifying the subscriber through the user terminal that the threshold has been 
reached; and 

(E) enabling the subscriber an opportunity to add to the account balance using the 
user terminal. 

2. The method of claim 1 , the method further comprising: 

(F) providing a plurality of options to the subscriber through the user terminal for 
proceeding in response to the threshold being reached, the plurality of options including the 
opportunity to add to the account balance. 

3 . The method of claim 1 , wherein the threshold is a prepaid threshold. 

4. The method of claim 1 , wherein the threshold is a spending limit. 

5 . The method of claim 1 , further comprising: 

(F) maintaining values for one or more session states for the session from a time at 
which the threshold was reached, while enabling the subscriber the opportunity to add to the 
account balance. 

6. The method of claim 1 , further comprising: 

(F) providing a proxy for the user terminal that exchanges communication with the 
server to maintain the session in place of the user terminal while enabling the subscriber the 
opportunity to add to the account balance. 
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7. The method of claim 6, wherein the proxy serves as a proxy for the server and 
exchanges communication with the user terminal to maintain the session in place of the 
server while enabling the subscriber the opportunity to add to the account balance 

5 8. The method of claim 1 , further comprising: 

(F) buffering session content transmitted by the server while enabling the subscriber 
the opportunity to add to the account balance. 

9. The method of claim 8, further comprising: 
1 0 (G) after the subscriber has added to the account balance, transmitting the buffered 

session content to the u 



1 0. The method of claim 9, further comprising: 

(H) suspending values for one or more session states for the session from when the 
15 threshold was reached, while enabling the subscriber the opportunity to add to the account 

balance. 

1 1 . The method of claim 10, further comprising: 

(I) after the buffered content has been transmitted to the user terminal, restoring the 
20 session using the values suspended from when the threshold was reached. 

12. The method of claim 1, further comprising: 

(F) in response to the subscriber adding to the account balance, recalculating the 
threshold. 

25 

1 3 . The method of claim 1 2, further comprising: 

(G) resuming the session; and 

(H) metering against the recalculated threshold. 



30 



14. The method of claim 1 , further comprising: 

(F) establishing another session between the user terminal and a server while 
enabling the subscriber the opportunity to add to the account balance, the other session 
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providing a free service to the subscriber. 

15. The method of claim 14, further comprising: 

(G) terminating the session before establishing the other session. 

5 

1 6. The method of claim 15, further comprising: 

(H) continuing the session using an alternative payment method while enabling the 
subscriber the opportunity to add to the account balance. 

10 17. The method of claim 1 , wherein the user terminal is a mobile terminal. 

1 8 . The method of claim 1 , wherein the amount is an amount of time. 

1 9. The method of claim 1 , wherein the amount is a volume of bytes. 

15 

20. The method of claim 1 , wherein the amount is a charge for an event. 

21 . The method of claim 1 , wherein act (D) includes: 

notifying the subscriber by including notification information in a packet transmitted 
20 as part of the session. 

22. The method of claim 1 , wherein act (D) includes: 

notifying the subscriber by establishing another session including the user terminal, 
and including notification information in a packet transmitted as part of the other session. 

25 

23 . The method of claim 1 , wherein act (D) includes: 

notifying the subscriber by sending a Short Message Service message to the user 
terminal. 



30 



24. The method of claim 1, wherein act (E) includes: 

enabling the subscriber an opportunity to add to the account balance as part of the 
session. 
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25. The method of claim 1, wherein act (E) includes: 

enabling the subscriber an opportunity to add to the account balance using another 
session with the user terminal. 

5 26. The method of claim 1, further comprising: 

implementing the session using a multimedia control protocol. 

27. The method of claim 26, wherein the multimedia control protocol is Internet 
protocol-based. 

10 

28. The method of claim 26, wherein the multimedia control protocol is one of the 
following: Session Initiation Protocol, Telephony Application Programming Interface, 
Telephony Server Application Programming Interface, H.323, Media Gateway Control 
Protocol, MEGACO, Open Services Architecture, PARLAY, Java Advanced Intelligent 

15 Network. 

29. The method of claim 1, wherein the user terminal is capable of playing video and act 
(D) includes: 

notifying the subscriber by transmitting a video to the user terminal. 

20 

30. The method of claim 1, wherein the user terminal is capable of displaying an image 
and act (D) includes: 

notifying the subscriber by transmitting an image to tire user terminal. 

25 31. The method of claim 1 , wherein the user terminal is capable of playing audio and act 
(D) comprises notifying the subscriber by transmitting audio to the user terminal. 

32. The method of claim 1, wherein the session involves the exchange of at least audio 
content formatted in a first format, and act (D) comprises: 
30 notifying the subscriber as part of the session using audio content formatted in the 

first format. 
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33 . The method of claim 1 , wherein the session involves the exchange of at least video 
content formatted in a first format, and act (D) comprises: 

notifying the subscriber as part of the session using video content formatted in the 
first format. 

5 

34. The method of claim 1 , wherein the session involves the exchange of multiple forms 
of media content. 

3 5 . The method of claim 1 , wherein the session is packet-switched. 

10 

36. The method of claim 1 , wherein the session is circuit-switched. 

37. A system for providing a session between a user terminal used by a subscriber and a 
server of a communications network providing a service to the subscriber, wherein the 

1 5 session involves the exchange of at least one of data content and video content, and the 
subscriber has a account balance for the service, the system comprising: 

a session support module to mamtaining a threshold for the service during the 
session, the threshold corresponding to the account balance, to meter an amount of the 
service used during the session, and to determine that the threshold has been reached; 

20 means for notifying the subscriber through the user terminal that the threshold has 

been reached; and 

means for enabling the subscriber an opportunity to add to the account balance using 
the user terminal. 

25 38. A computer program product, comprising: 
a computer-readable medium; and 

computer-readable signals stored on the computer-readable medium that define 
instructions that, as a result of being executed by a computer, instruct the computer to 
perform a process of providing a session between a user terminal used by a subscriber and a 
30 server of a communications network providing a service to the subscriber, wherein the 
session involves the exchange of at least one of data content and video content, and the 
subscriber has a account balance for the service, the process comprising acts of: 

(A) maintaining a threshold for the service during the session, the threshold 
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corresponding to the account balance; 

(B) metering an amount of the service used during the session; 

(C) determining that the threshold has been reached; 

(D) notifying the subscriber through the user terminal that the threshold has been 
reached; and 

(E) enabling the subscriber an opportunity to add to the account balance using the 



39. A method of enabling the subscriber an opportunity to add to a balance for a service 
provided during a session between a user terminal used by a subscriber and a server of a 
communications network providing the service to the subscriber, the method comprising 
acts of: 

(A) buffering session content transmitted by the server to the user terminal as part of 
the session while enabling the subscriber the opportunity to add to the account balance. 

40. The method of claim 39, further comprising: 

(B) after the subscriber has added to the account balance, transmitting the buffered 
session content to the user terminal. 

4 1 . The method of claim 40, further comprising: 

(C) maintaining values for one or more session states for the session from a time at 
which the threshold was reached, while enabling the subscriber the opportunity to add to the 
account balance. 



25 42. The method of claim 4 1 , further comprising: 

(D) after the buffered content has been transmitted to the user terminal, restoring the 
session using the values suspended from when the threshold was reached. 

43 . The method of claim 39, wherein the session involves the exchange of at least one of 
30 data content and video content. 

44. A system for enabling the subscriber an opportunity to add to a balance for a service 
provided during a session between a user terminal used by a subscriber and a server of a 
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communications network providing the service to the subscriber, the system comprising: 

means for buffering session content .transmitted by the server to the user terminal as 
part of the session while enabling the subscriber the opportunity to add to the account 
balance. 



45. A computer program product, comprising: 
a computer-readable medium; and 

computer-readable signals stored on the computer-readable medium that define 
instructions that, as a result of being executed by a computer, instruct the computer to 
1 0 perform a process of enabling the subscriber an opportunity to add to a balance for a service 
provided during a session between a user terminal used by a subscriber and a server of a 
communications network providing the service to the subscriber, the method comprising 
acts of: 

(A) buffering session content transmitted by the server to the user terminal as part of 
15 the session while enabling the subscriber the opportunity to add to the account balance. 



46. The computer program product of claim 45, wherein the process further comprises: 

(B) after the subscriber has added to the account balance, transmitting the buffered 
session content to the user terminal. 

20 

47. The computer program product of claim 46, wherein the process further comprises: 

(C) maintaining values for one or more session states for the session from a time at 
which the threshold was reached, while enabling the subscriber the opportunity to add to the 
account balance. 

25 

48. , The computer program product of claim 47, wherein the process further comprises : 

(D) after the buffered content has been transmitted to the user terminal, restoring the 
session using the values suspended from when the threshold was reached. 



30 49. The computer program product of claim 45, wherein the session involves the 
exchange of at least one of data content and video content. 
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50. A method of notifying a subscriber that a threshold amount of service corresponding 
to an account balance for a service has been reached during a session between a user 
terminal used by a subscriber and a server of a communications network providing the 
service to the subscriber, wherein the session involves the exchange in a first format of at 

5 least one of video content and audio content, the method comprising acts of: 

(A) notifying the subscriber that the threshold has been reached as part of the session 
using the at least one of video content and audio content formatted in the first format. 

5 1 . The method of claim 50, wherein the session involves the exchange of video content 
10 formatted in the first format, and act (A) comprises: 

notifying the subscriber as part of the session using video content formatted in the 
first format. 



52. The method of claim 50, wherein the session involves the exchange of audio content 
15 formatted in the first format, and act (A) comprises: 

notifying the subscriber as part of the session using audio content formatted in the 
first format. 



53 . The method of claim 50, further comprising acts of: 

20 controlling the session using a multimedia protocol, including controlling the 

notification using the multimedia protocol. 

54. A system for notifying a subscriber that a threshold amount of service corresponding 
to an account balance for a service has been reached during a session between a user 

25 terminal used by a subscriber and a server of a communications network providing the 
service to the subscriber, wherein the session involves the exchange in a first format of at 
least one of video content and audio content, the system comprising: 

means for notifying the subscriber that the threshold has been reached as part of the 
session using the at least one of video content and audio content formatted in the first 

30 format. 



55. A computer program product, comprising: 
a computer-readable medium; and 
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computer-readable signals stored on the computer-readable medium that define 
instructions that, as a result of being executed by a computer, instruct the computer to 
perform a process of notifying a subscriber that a threshold amount of service corresponding 
to an account balance for a service has been reached during a session between a user 
5 terminal used by a subscriber and a server of a communications network providing the 
service to the subscriber, wherein the session involves the exchange in a first format of at 
least one of video content and audio content, the process comprising acts of: 

(A) notifying the subscriber that the threshold has been reached as part of the session 
using the at least one of video content and audio content formatted in the first format. 

10 

56. The computer program product of claim 50, wherein the session involves the 
exchange of video content formatted in the first format, and act (A) comprises: 

notifying the subscriber as part of the session using video content formatted in the 
.first format. 

15 

57. The computer program product of claim 50, wherein the session involves the 
exchange of audio content formatted in the first format, and act (A) comprises: 

notifying the subscriber as part of the session using audio content formatted in the 
first format. 

20 

58. The computer program product of claim 50, wherein the process further comprises 
an act of: 

controlling the session using a multimedia protocol, including controlling the 
notification using the multimedia protocol. 
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